| Internet-Draft | ROSA | July 2023 |
| Trossen, et al. | Expires 10 January 2024 | [Page] |
The term 'service-based routing' (SBR) captures the set of mechanisms for the steering of traffic in an application-level service scenario. As in the related use case and gap analysis drafts, we position this steering as an anycast problem, requiring the selection of one of the possibly many choices for service execution at the very start of a service transaction.¶
This document outlines a possible architecture for realizing SBR so as to address the issues identified in the use case and gap analysis companion documents, specifically aiming at the realization of the requirements in the latter document. We outline the architecture, with pointers to possible realizations of the interactions, while also outlining possible extensions to a base SBR capability through a ROSA system as an outlook to possible richer capabilities.¶
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 10 January 2024.¶
Copyright (c) 2023 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.¶
As noted already in [I-D.mendes-rtgwg-rosa-use-cases], we can recognize a growing proliferation of serverless service provisioning methods that allow for dynamically deploying service endpoints, not just in centralized data centres but distributed across network locations and end devices, including those provided by end users directly.¶
As identified in [I-D.mendes-rtgwg-rosa-use-cases], the key problem in providing services in a distributed setting is that of mapping an application level identifier, e.g., a domain name, to a routing locator under which the device hosting a service could be reached. We refer to this as 'service-based routing' (SBR). As further identified in [I-D.mendes-rtgwg-rosa-use-cases], a key problem to SBR is the possible latency that may incur for such mapping operation, while also enabling dynamic updates to the mapping result, possibly constrained by service-specific policies.¶
Overall, we characterize SBR in an environment that makes use of, possibly virtualized and distributed service endpoints in several network locations, as needing to make any anycast decision, selecting one out of possibly many choices for the service endpoint, where such choice may change frequently.¶
In the remainder of this document, we present an architecture for such anycast decision method, addressing the key issues outlined in [I-D.mendes-rtgwg-rosa-use-cases] in an approach we term 'routing on service addresses', or ROSA in short. In summary to the issues identified in [I-D.mendes-rtgwg-rosa-use-cases], the main design goals for ROSA can be identified as (i) supporting the need for 'dynamicity' for the anycast decision, (ii) providing the required 'efficiency' of the anycast decision to improve on existing explicit resolution methods (and their incurring latency through the required resolution step) as well as (iii) enable the 'service specificity' of the anycast decision.¶
The key approach to Routing on Service Addresses (ROSA) is to replace the usual DNS+IP sequence, i.e., the off-path discovery of service name to IP locator mapping, through an in-band discovery to a suitable service instance location for a selected set of services, not all Internet-based services, followed by the usual direct client-service transfer using existing IP-based data path solutions.¶
With this in mind, the basic functionality of ROSA can be described as follows:¶
Steps 1 through 4 are repeated for every new service transaction, allowing those transactions now to be served at any of the available service instances albeit keeping one transaction at one chosen service instance! Steps 1 through 4 may also be repeated in case of mobility. For stateless services, only steps 1, 2, and 3 are executed.¶
In order to react to system, e.g., network but more importantly service changes, ROSA achieves dynamicity, as mentioned in the previous section, by employing a routing-based approach able to map service addresses to routing locators, where mappings of service addresses to routing locators are pushed to the (shim overlay) elements, enabling to perform the translation from a service addressed packet to an IP-addressed packet on the data path. When using, e.g., eBPF-based techniques in SW-based routers, such approach can achieve 100s of thousands of resolution steps per ingress node, as discussed in Section 5.¶
The above functionality may be realized at various layers, which a wider architectural discussion on ROSA will need to investigate further. For instance, one could apply the above capability through an application layer protocol, such as HTTP, akin to what ALTO proposes (or as an extension to ALTO solutions). Alternatively, methods developed by the MASQUE WG could be used (and suitably extended) to employ a transport level realization of the in-band functionality.¶
While we do not intend to pre-empt any conclusion of this architectural debate, we intend to outline an example design in this document that provides what we see as the lowest possible layer realization. Specifically, we outline the realization at L3.5, employing an IPv6 extension header based approach. This approach preserves a key assumption for a realization of the above functionality, namely to be realized as an overlay, thus not being linked into necessary ISP-level deployments, but operate akin to choosing your DNS server at the client, thus fostering the possible privacy of communication between clients and a set of services.¶
Furthermore, we believe that this chosen level of realization allows for the broadest support for transport and application protocols alike since the initial IP packet, realizing the in-band resolution step, can include upper layer, i.e., transport and/or application-level, data within the normal payload of the IP packet, achieving the desired removal of the explicit resolution step as we use today through the additional EH content.¶
Additionally, similar to application-level solutions, the positioning as a (L3.5) shim overlay facilitates the exposure of service-specific selection policies from the service to a ROSA provider through explicit commercial relations, separate from those defining the routing policies in the underlay network.¶
Unlike deploying name-based routing solutions at the underlay, scalability here is achieved by limiting the resolution to those services explicitly announced to the service routing (i.e., ROSA) overlay. Thus, ROSA does not aim to replace ALL service routing through the above proposed steps, but focus on those services explicitly announcing their desire for a ROSA-based resolution to an appropriate ROSA provider. The assumed explicit (often commercial) relationship between the service provider and the ROSA provider is what allows for controlling the scalability requirements of the elements realizing the ROSA overlay.¶
In the remainder of this document, we first introduce in Section 2 a terminology that provides the common language used for the wider ROSA work. We then outline the design in Section 3 with possible extensions to this basic design discussed in Section 4, leaving space for insights from an early implementation of such design in Section 5.¶
The following terminology is used throughout the remainder of this document:¶
This section outlines the design of a shim layer relying upon IPv6 to provide routing on service addresses (ROSA). It first outlines the system overview, before outlining the possible interfaces to the IP layer (Section 3.2 and applications in ROSA endpoints (Section 3.3), followed with the various operational methods of ROSA in terms of forwarding operations (Section 3.4), traffic steering methods (Section 3.5), and interconnection (Section 3.6).¶
Figure 1 illustrates a ROSA domain, interconnected to other ROSA-supporting domains via the public Internet through the Service Address Gateway (SAG), where a ROSA domain may span one or more IPv6 underlay domain. Section 3.6 provides more detail on how to achieve interconnection between ROSA domains.¶
ROSA is positioned as a shim overlay atop IPv6, using Extension headers that carry the suitable information for routing and forwarding the ROSA service requests, unlike [I-D.eip-arch] which proposes to include extension processing directly into the transport network.¶
+-----------+ +-----------+ +-------+
+service.org+ +service.org+ +foo.com|
+----+------+ +-------+---+ +----+--+
| | |
+-----------+ +----+-+ +----+-----------+--+
+service.org+---+DC Net| | DC Net |
+-----------+ +---+--+ +-------------+-----+
| |
+-+--+ +-+--+
+-----+SAR4| |SAR5|
| +-+--+ +-+--+
+------+ +-+--+ +----+ |
+Client+--------+SAR1+-------------+ +SAR6+ |
+------+ +----+ | +-+--+ |
| | |
+------+ +----+ ++-----+----+ |
+Client+--------+SAR2+------------+IPv6 Net(s)+---------+
+------+ +----+ +---+--+----+ (----)
| | ( )
+------------------+ +----+ | | +----+ ( Other )
+MyMobile.org/video+--------+SAR3+----+ +----+SAG1+----( Domains )
+------------------+ +----+ +----+ ( )
(------)
SAR: Service Address Router
SAG: Service Address Gateway
ROSA endpoints start with discovering their ingress Service Address Router (SAR), e.g., through DHCP extensions or through utilizing the Session Management Function (SMF) in 5G networks [TS23501]. An endpoint may discover several ingress SARs for different categories of services, each SAR being part of, e.g., a category-specific ROSA overlay, which in turn may be governed by different routing policies and differ in deployment (size and capacity). The category discovery mechanism may be subject to specific deployments of ROSA and thus is likely outside the scope of this document at this point.¶
Services are realized by service instances, possibly at different network locations. Those instances expose their availability to serve requests through announcing the service address of their service to their ingress SAR, which in turn distributes suitable ROSA routing state across the SARs in its domain. The lacking tie of service addresses to the network topology, and thus the lacking possibility to aggregate relationships of service addresses to routing locators, poses a scalability challenge (specifically to address Req 2.a in Section 3.4) However, the routing tables in ROSA are bounded by the number of services explicitly announcing their service to ingress SARs, while utilizing explicit interconnection (see Section 3.6) to other ROSA domains or the Internet for any service requested in the domain that has not previously been announced.¶
To invoke a service, a ROSA client sends an initial request, addressed to a service, to its ingress SAR, which in turn steers the request (possibly via other SARs) to one of possibly many service instances. See Section 3.4 for the required SAR-local forwarding operations and end-to-end message exchange and Section 3.3 for the needed changes to ROSA clients. Conversely, non-ROSA services may continue to be invoked using existing means for service routing, such as DNS, GSLB, Alto and others.¶
We refer to initial requests as 'service requests'. If an overall service transaction creates ephemeral state, the client may send additional requests to the service instance chosen in the (preceding) service request; we refer to those as 'affinity requests'. With this, routing service requests (over the ROSA network) can be positioned as on-path service discovery (winth in-band data), contrasted against explicit, often off-path solutions such as the DNS.¶
In order to support transactions across different service instances, e.g., within a single DC, a sessionID may be used, as suggested in [SOI2020]. Unlike [SOI2020], discovery does not include mapping abstract service classes onto specific service addresses, avoiding semantic knowledge to exist in the ROSA shim layer for doing so.¶
With the above, we can outline the following design principles that guide the development for the solutions described next:¶
We can recognize similarities of these principles with those outlined for the Locator Identifier Separation Protocol (LISP) in [RFC9299] albeit extended with using direct IP communication for longer service transactions.¶
Apart from affinity requests, which utilize standard IPv6 packet exchange between the client and the service instance selected through the initial service request, ROSA introduces three new message types. Here, we present example encodings, shown in Figure 2.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Instance=IP |
| Service=ID |
| Constraint=txt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Announcement
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Client=IP |
| Ingress=IP |
| Service=ID |
| Port=port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Request
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Client=IP |
| Ingress=IP |
| Service=ID |
| Port=port |
| Instance=IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Response
Given the overlay nature of ROSA, clients, SARs, and service instances are destinations in the IPv6 underlay of the network domains that the overlay spans across. This is unlike approaches such as [I-D.huang-service-aware-network-framework], which place the service address into the destination address of the respective IPv6 header field, although [I-D.ma-intarea-encapsulation-of-san-header] also foresees the encapsulation into the IPv6 EH, as suggested here.¶
Istead, we propose to use the destination option EH [RFC8200], where Figure 2 shows the options carried, proposed here as using a TLV format for the extension header with Concise Binary Object Representation (CBOR) [RFC8949] being studied as an alternative. The EH entries shown are populated at the client and service instance, while read at traversing SARs.¶
A service address is encoded through a hierarchical naming scheme, e.g., using [RFC8609]. Here, service addresses consist of components, mapping existing naming hierarchies in the Internet onto those over which to forward packets, illustrated in the forwarding information base (FIB) of Figure 3 as illustrative URLs. With components treated as binary objects, the hierarchical structure allows for prefix-based grouping of addresses, reducing routing table size, while the explicit structure allows for efficient hash-based lookup during forwarding operations, unlike IP addresses which require either log(n) radix tree search software or expensive TCAM hardware solutions.¶
Note that other encoding approaches could be used, such as hashing the service name at the ROSA endpoint or assigning a service address through a mapping system, such as the DNS, but this would require either additional methods, e.g., for hash conflict management or name-address mapping management, which lead to more complexity.¶
With the service announcement message, a service instance signals towards its ingress SAR its ability to serve requests for a specific service address. Section 3.5 outlines the use of this message in routing or scheduling-based traffic steering methods.¶
The service request message is originally sent by a client to its ingress SAR, which in turn uses the service address provided in the extension header to forward the request, while the selected service instance provides its own IP locator as an extension header entry in the service response. In addition to the service address, suitable port information is being provided (through upper layer protocols), allowing to associate future affinity requests with their initial service requests.¶
The next section describes the SAR-local forwarding operations and the end-to-end message exchange that uses the extension header information for traversing the ROSA network, while Section 3.6 outlines the handling of service addresses that have not been previously announced within the client-local ROSA domain.¶
Within endpoints, the ROSA functionality is realized as a shim layer atop IPv6 and below transport protocols. For this, endpoints need the following adjustments to support ROSA:¶
The SAR operations are typical for an EH-based IPv6 forwarding node: an incoming service request or response is delivered to the SAR forwarding engine, parsing the EH for relevant information for the forwarding decision, followed by a lookup on previously announced service addresses, and ending with the forwarding action.¶
Figure 3 shows a schematic overview of the forwarding engine with the forwarding information base (FIB) and the next hop information base (NHIB) as main data structures. The NHIB is managed through a routing protocol, see Section 3.5, with entries leading to announced services.¶
incoming service request/response
-------------------------------------|| Next Hop
\/ Information Base
Forwarding Information Base +----------+ +-+--------+----+
+------------------+--------+ |EH parsing| |#|Next Hop|Cost|
|Service address |Next Hop| +----||----+ |#| IP |Cost|
+------------------+--------+ \/ +-+--------+----+
| service.org | 4, 5, 0| +----------+ |0| SAR5 | 2 |
+------------------+--------+ | SAR | +-+--------+----+
| foo.com | 1 |-->|Forwarding| |1| SAR6 | 1 |
+------------------+--------+ | Decision | +-+--------+----+
|MyMobile.org/video| 2 | +----||----+ |2| SAR2 | 4 |
+------------------+--------+ \/ +-+--------+----+
| * | 3 | +----------+ |3| SAR1 | 2 |
+------------------+--------+ | SA/DA | +-+--------+----+
|Adjustment|<--|4| SI1 | - |
+----||----+ +-+--------+----+
\/ |5| SI2 | - |
+----------+ +-+--------+----+
|IP packet |
|forwarding| Outgoing service
| engine | request/response
+----------+------------------->
The FIB is dynamically populated by service announcements via the intyer-SAR routing protocol, with the FIB including only one (ROSA next hop) entry into the NHIB when using routing-based methods (rows 0 to 3 in Figure 3), described in Section 3.5.2. Scheduling-based solutions (see Section 3.5.1), however, may yield several dynamically created entries into the NHIB (items 0, 4 and 5 in Figure 3, where SI1 and SI2 represent the IPv6 address announced by the respective service instances) as well as additional information needed for the scheduling decision; those dynamic NHIB entries directly identify service instances locations (or their egress as in item 0) and only exist at ingress SARs towards ROSA clients.¶
We expect the number of forwarding entries to be limited by the explicit relations service providers may have with their ROSA provider. In other words, we do not expect the FIB to include ALL possible service names but those explicitly announcing their service (and being authorized by the ROSA provider doing so). In our use cases of [I-D.mendes-rtgwg-rosa-use-cases], those services may be very limited in numbers, particularly if we foresee dedicated ROSA providers to aim at realizing those use cases.¶
For a service request, a hash-based service address lookup (using the Service EH entry) is performed, leading to next hop (NH) information for the IPv6 destination address to forward to (the final destination address at the last hop SAR will be the instance serving the service request).¶
Forwarding the response utilizes the Client and Ingress EH fields, where the latter is used by the service instance's ingress SAR to forward the response to the client ingress SAR, while the former is used to eventually deliver the response to the client by the client's ingress SAR, ensuring proper firewall traversal of the response back to the client. We have shown in prototype realizations of ROSA that the operations in Figure 3 can be performed using eBPF [eBPF] extensions to Linux SW routers, while [SarNet2021] showed the possibility a realizing a similar design using P4-based platforms.¶
Client Ingress Service Service
SAR Instance Instance
(CIP) (SAR IP) (SI1 IP) (SI2 IP)
---------------------------------------------------------------------
ServiceRequest
(ClientIP,SAR IP)
(CIP, SAR IP, ServiceID)
--------------------->
\ Determine ROSA
/ and, ultimately, IP Next Hop
ServiceRequest
(SAR IP, SI1 IP)
(CIP, SAR IP, ServiceID)
--------------------->
\ Generate
/ Response
ServiceResponse
(SI1 IP, SAR IP)
(CIP, SAR IP, ServiceID, SI1 IP)
<---------------------
ServiceResponse
(SAR IP, CIP)
(CIP, SAR IP, ServiceID, SI1 IP)
<---------------------
AffinityRequest
(CIP, SI1 IP)
------------------------------------------->
\ Generate
/ Response
<-------------------------------------------
Figure 4 shows the resulting end-to-end message exchange, using the aforementioned SAR-local forwarding decisions. We here show the IP source and destination addresses in the first brackets and the extension header information in the second bracket.¶
We can recognize two key aspects. First, the SA/DA re-writing happens at the SARs, using the EH-provided information on service address, initial ingress SAR and client IP locators, as described above. Second, the selection of the service instance is signalled back to the client through the additional Instance EH field, which is used for sending subsequent (affinity) requests via the IPv6 network. As noted in the figure, when using transport layer security, the service request and response will relate to the security handshake, thereby being rather small in size, while the likely larger HTTP transaction is sent in affinity requests. As discussed in Section 8, 0-RTT handshakes may result in transactions being performed in service request/response exchanges only.¶
Traffic steering in ROSA is applied to service requests for selecting the service instance that may serve the request, while affinity requests use existing IPv6 routing and any policies constraining traffic steering in this part of the overall system. At receiving service endpoints, service provisioning platforms may use additional methods to schedule incoming service requests to suitable resources with the ingress point to the service provisioning platform being the service endpoint for ROSA.¶
In the following, we outline two approaches for traffic steering. The first uses ingress-based scheduling decisions to steer traffic to one of the possible service instances for a given service address. The second follows a routing-based model, determining a single destination for a given service address using a routing protocol, similar to what is suggested in [I-D.huang-service-aware-network-framework].¶
We envision that some services may be steered through scheduling methods, while others use routing approaches. The indication which one to apply may be derived from the number of next hop entries for a service address. In Figure 3, service.org uses a scheduling method (with instances connected to SAR5 being exposed as a single instance to ROSA, using DC-internal methods for scheduling incoming requests), while the other services are routed via SARs.¶
We furthermore envision an interface to exist between the ROSA provider and the underlying network provider, exchanging routing policy relation information. The richness of this interface depends on the specific business relation between both providers, i.e., the ROSA and the network provider. In integrated settings, where ROSA and network provider may belong to the same commercial entity, this interface may provide rich routing policy relation information, such as network latency and bandwidth information, which in turn may be used in the ROSA traffic steering decisions. In other, more disintegrated deployments, the information may entirely be limited to SLA-level information with no specific runtime information exchanged between both providers. The exact nature of this interface remains for further study.¶
Important here is that traffic steering is limited to a single ROSA domain, i.e., traffic steering is not provided across instances of the same service in different ROSA domains; traffic will always be steered to (ROSA) domain-local instances only.¶
Traffic steering through explicit request scheduling follows an approach similar to application- or transport-level solutions, such as GSLB [GSLB], DNS over HTTPS [RFC8484], HTTP indirection [RFC7231] or QUIC-LB [I-D.ietf-quic-load-balancers]: Traffic is routed to an indirection point which directs the traffic towards one of several possible destinations.¶
In ROSA, this indirection point is the client's ingress SAR. However, unlike application or transport methods, scheduling is realized in-band when forwarding service requests in the ingress SAR, i.e., the original request is forwarded directly (not returned with indirection information upon which the client will act), while adhering to the affinity of a transaction by routing subsequent requests in a transaction using the instance's IP address. Scheduling commences to a possibly different instance with the start of a new transaction.¶
For this, the ingress SAR's NHIB needs to hold information to ALL announced service instances for a service address. Furthermore, any required information, e.g., capabilities or metric information, that is used for the scheduling decision is signalled via the service announcement, with (frequent) updates to existing announcements possible. Announcements for services following a scheduling- rather than a routing-based steering approach carry suitably encoded information in the Constraint field of the announcement's EH, leading to announcements forwarded to client-facing ingress SARs without NHIB entries stored in intermediary SARs.¶
In addition, a scheduling decision needs to be realized in the SAR forwarding decision step of Figure 3. This may require additional information to be maintained, such as instance-specific state, further increasing the additional NHIB data to be maintained. Examples for scheduling decisions are:¶
Although each method yields specific performance benefits, e.g., reduced latency or smooth load distribution, [OnOff2022] outlines simulation-based insights into benefits for realising the compute-aware solution of [CArDS2022] in ROSA.¶
In order to send a service request to the `best' service instance (among all announced ones) using a routing-based approach, we build NHIB routing entries by disseminating a service instance's announcement for a given service address S, arriving at its ingress SAR. This distribution may be realized via a routing protocol or a central routing controller or a hybrid solution.¶
If no particular constraint is given in the announcement's EH Constraint field, shortest path will be realized as a default policy for selecting the `best' instance, routing any client's request to S the nearest service instance available.¶
Alternatively, selecting a service instance may use service-specific policies (encoded in the Constraint field of the EH, with the specific encoding details being left for future work). Here, multiple constraints may be used, with [Multi2020] providing a framework to determine optimal paths for such cases, while also conventional traffic engineering methods may be used.¶
Through utilizing the work in [Multi2020], a number of multi-criteria examples can be modelled through a dominant path model, relying on a partial order only, as long as isotonicity is observed. Typical examples here are widest-shortest path or shortest-widest routing (see [Multi2020]), which allow for performance metrics such as capacity, load, rate of requests, and others. However, metrics such as failure rate or request completion time cannot directly be captured and need formulation as a max metric. Furthermore, metrics may not be isotonic, with Section 3.4 of [Multi2020] supporting those cases through computing a set of dominant attributes according to the largest reduction. [Multi2020] furthermore shows that non-restarting or restarting vectoring protocols may be used to compute dominant paths and to distribute the routing state throughout the network.¶
However, the framework in [Multi2020] is limited to unicast vectoring protocols, while the routing problem in ROSA requires selecting the 'best' path to the 'best' instance, i.e., as an anycast routing problem. To capture this, [Multi2020] could be extended through introducing a (anycast) virtual node, placed at the end of a logical path that extends from each service instance to the virtual node. Selecting the best path (over the announced attributes of each service instance) to the virtual node will now select the best service instance (over which to reach the virtual node in the logically extended topology).¶
Alternatively, ROSA routing may rely on methods for anycast routing, but formulated for service instead of anycast addresses. For instance, AnyOpt [AnyOpt2021] uses a measurement-based approach to predict the best (in terms of latency) anycast (i.e. service) instance for a particular client. Alternatively, approaches using regular expressions may be extended towards spanning a set of destinations rather than a single one. Realizations in a routing controller would likely improve on convergence time compared to a distributed vector protocol; an aspect for further work to explore.¶
There are two cases for interconnection: access to (i) non-ROSA services in the public Internet and (ii) ROSA services not domain-locally announced but existing in other domains.¶
For both cases, we utilize a reserved wildcard service address '*' that points to a default route for any service address that is not being advertised in the local domain. This default route is the service address gateway (see Figure 1), ultimately receiving the service request to the locally unknown service.¶
Upon arriving at the SAG, it searches its local routing table for any information. If none is found, it consults the DNS to retrieve an IP address where the service is hosted; those mappings could be cached for improving future requests or being pre-populated for popular services.¶
For case (i), the resolution returns a server's IP address to which the SAG sends the service request with its own IP address as source address. The service response is routed back via the SAG, which in turn uses the Ingress EH information to return the response to the client via its ingress SAR.¶
For case (ii), the IP address would be that of the SAG of the ROSA domain in which the service is hosted. For this, a domain-local service instance would have exposed its service, e.g., Mobile.com/video Figure 1, by registering its domain-local SAG IP address with the mapping service. To suitably forward the request, the SAG adds its own IP address as the value to an additional SAG label into the extension header. At the destination SAG, the service address information, extracted from the extension header, is used to forward the service request based on ROSA mechanisms. For the service response, the destination SAG uses the SAG entry in the EH to return the response to the originating ROSA domain's SAG, which in turn uses the Ingress information of the EH to return the response via the ingress to the client.¶
Given the EH deployment issues pointed out in [SHIM2014], a UDP-based encapsulation may overcome the observed issues, not relying on the EH being properly observed during the traversal over the public Internet. Furthermore, while Figure 1 shows the SAG as an independent component, we foresee deployments in existing PoPs. This would allow combining provisioning through frontloaded PoP-based services and ROSA services. Any service not explicitly announced in the ROSA system would lead to being routed to the PoP-based SAG, which may use any locally deployed services before forwarding the request to the public Internet.¶
ROSA, as defined in Section 3, can be extended to address various capabilities useful for specific or across a number of use cases. The following provides a list of those possible extended capabilities. At this stage, we would expect those capabilities to be defined in more detail in separate drafts, complementing the ROSA 'base' specification, as defined in this current draft.¶
Although most of our examples assume the use of URL-based service addresses, encoded using [RFC8609], supporting other, e.g., corporate service, namespaces may be desired. [RFC8609] generally supports this and could thus be used.¶
As briefly alluded to in Section 3.2, other encodings to that following [RFC8609] may be used, focussing on different ways to represent a service address differently, including linking it to the service name used at the application level.¶
One such encoding may be that of a unique service address per service name, with the linkage between both provided through the DNS. Here, the client sends an initial DNS query with the URL of the purported service or application. Instead of requesting a resolution to a locator, however, is the request for mapping between the URL and the service address of ROSA, where the service address has been assigned as part of the domain name registration (which may be done after initial registration of the domain name for backward compatibility). Service addresses here may be simply encoded as numerals, where uniqueness is achieved through linking to the domain name registration and thus DNS mapping. Encoding in the respective EH header field (see Section 3.2) would be shorter and thus more efficient, still achieving the desired uniqueness in the SAR forwarding process to avoid ambiguity in forwarding decisions. The drawback is the need for the additional DNS mapping step (albeit only required once per application, where the service address could be stored persistently for later use), while also the additional DNS mapping will need standardization (likely in the form of a new DNS record).¶
Another possible encoding, without the aforementioned explicit DNS mapping step, could be to explicitly hash the service name into a service address at the ROSA endpoint, operating on those hash values for service announcement and requests. Due to the large service namespace, hash conflicts may, however, occur, which needs resolving at the SAR (which may operate on a service address for a service request for a different, but same hashed, service address of an announcement service). Further study is needed into the probability for such hash conflicts and possible mitigation methods for such conflicts.¶
If the use of different encoding methods beyond [RFC8609] was to be considered, appropriate modifications to the EH fields need to be done to signal the used encoding method for the service address.¶
Multi-homed service instances may benefit from path-aware routing decisions after mapping service addresses to service instance addresses. To that end, service instances would need to advertise multiple instance IPs as part of their service announcement.¶
The optimal path may differ while a client communicates with a service instance; this is in particular likely for mobile clients. This provides some complication for affinity requests; in such a case, the service instance IP is no longer sufficient to identify a service instance, merely to locate a particular path.¶
Multi-homing issues in connection with aircrafts also extend to Unmanned Aircraft Systems (UAS). Rather than focusing on passenger experience, multi-homing over commercial off-the-shelf (COTS) communications modules such as 5G or IEEE 802.11 provides command, control and communications (C3) capabilities to Unmanned Aerial Vehicles (UAV; drones). Despite the difference in focus, the technical challenges in maintaining connection quality are largely equivalent.¶
Multi-homing thus either requires an undesirable further resolution step from a service instance identifier to a (optimal path) locator. Alternatively, ROSA message types may be extended to include a distinct service instance identifier and service instance locator identifiers, i.e., IP addresses, which provides sufficient information for SARs to map to specific and changing locators, while retaining the affinity to the service instance by identifier.¶
TBD Dirk¶
When it comes to the transaction mobility in which the serving service instance needs to be shifted to another selected alternative instance, the ROSA service address could provide a good starting as an location-independent ID. Other than TCP for which the client and server have to maintain strict machine state, UDP-based protocol could be extended with the service address to be treated as the connection ID rather than the traditional 4-tuple including the host destination address when the server does not have to maintain session state. The chief gain here is the service connection could remain intact when the serving service instance has been switched over at ROSA level (routing plane).¶
As part of the ability to switch over from one service instance, ROSA may explicitly support that mobility in that the choice of the (new) service instance is explicitly made within the service-specific traffic steering method. For this, ROSA may introduce a separate message alongside the service request message (see see Section 3.2), which not only allows for the ingress SAR to perform the same routing policy as if it was sent through a new service request message, but may also include application-specific context data to facilitate the needed application state transfer from the original service instance to the new one. Here, the in-band capability of a ROSA request is being used to carry this context data as part of the new ROSA message.¶
Service Function Chaining (SFC) [RFC7665] allows for chaining the execution of services at L2 or L3 level, targeting scenarios such as carrier-grade NAT and others. The work in [RFC8677] extends the chaining onto the name level, using service names to identify the individual services of the chain, even allowing combinations of name and L2/L3-based chains.¶
Although [RFC8677] is tied into a realization of the SFF (service function forwarder) using a path-based forwarding approach, the concept of name-based SFCs can equally be realized utilizing ROSA.¶
The exposure of service-related information in the ROSA EHs may be seen as a privacy issue, particularly when utilizing the service name as the basis for the service address formulation. Although Section 8 outlines the possible use of service categories (instead of finer-grained service names) as input into the service address formulation, it is also desirable to protect the privacy of fine-grained service address information, should the specific ROSA deployment make use of them.¶
Beyond using encryption methods to protect the ROSA EH information, such privacy methods could also include the obfuscation of client and transit information as well, thus moving into the space of routing privacy, as outlined for instance in [I-D.ip-address-privacy-considerations]¶
To come before IETF118 with description of planned demo to demonstrate some of the benefits for using ROSA.¶
There are a number of open issues with the following list providing a non-exhaustive list of examples:¶
This draft outlined an architecture for service-specific traffic steering as an alternative to existing service-based routing methods that use explicit resolution steps. Instead, the architecture presented in this document advocates an approach of in-band signalling of service addresses, possibly carried across IPv6 EH-based shim overlay, followed by the IPv6-based transfer of subsequent packets in similarity to existing SBR methods. The architecture suggests to employ routing and ingress scheduling based methods to provide the desired dynamicity of anycast decisions that are outlined as desirable for the use cases in [I-D.mendes-rtgwg-rosa-use-cases].¶
As next steps, we plan on extending various aspects of the ROSA operations, e.g., describing control plane aspects such as SAR discovery as well as a possible routing protocol. We expect that some of those aspects, such as for a ROSA control plane, are captured in separate works.¶
We furthermore have plans on bringing an eBPF-based prototypical realization of the forwarding behaviour in Section 3.4 to future IETF events, e.g., for a hackathon participation to showcase ROSA-based applications in a test setup.¶
Aligned with security considerations in existing service provisioning systems, we address aspects related to authenticity, i.e., preventing fake service announcements, confidentiality, both in securing relationship as well as payload information, and operational integrity.¶
The exposure of service-related information in the ROSA EHs may be seen as a privacy issue, particularly when utilizing the service name as the basis for the service address formulation. As discussed in Section 4.6, extensions to the base ROSA capabilities may address this issue to ensure the privacy of the clients' communication relations in ROSA deployments, where needed.¶
This draft does not request any IANA action.¶
Many thanks go to Ben Schwartz, Luigi Iannone, Mohamed Boucadair, Tommy Pauly, Joel Halpern, Daniel Huang, and Russ White for their comments to the text to clarify several aspects of the motiviation for and technical details of ROSA.¶