Rapid.space

86 avenue de la République Paris 75011 France titouan.soulard@rapid.space

Operations and Management Area Autonomic Networking Integrated Model and Approach This document analyzes challenges for using the GeneRic Autonomic Signaling Protocol (GRASP) in the context of deployment of services on machines (servers, Virtual Machines, etc) without the network elements, such as routers, needing any support for GRASP by themselves. It analyses issues regarding the discovery mechanism, including discovery across subnets and operation across administrative boundaries, and provides terminology and general considerations for the development of future extensions, profiles, and architectural refinements.

Introduction The GeneRic Autonomic Signaling Protocol (GRASP) was specified as a common signaling substrate to decentralize the logic of network management . It provides mechanisms for discovery, negotiation, and synchronization between Autonomic Service Agents, without making assumptions about the devices employed or the underlying security layer. Experience with autonomic networking and GRASP already prompted interest in adapting the protocol for use in a broader range of environments, with the emergence of the Constrained GeneRic Autonomic Signaling Protocol (cGRASP) . In the meanwhile, there is a lack of standard for the deployment of Autonomic Functions when these functions are not run on Autonomic Nodes being network elements, but on computers inside the network that take no active role in networking. Using GRASP outside Autonomic Networks with ubiquitous GRASP support would offer several potential benefits. As such, it would enable a unified discovery and negotiation mechanism for autonomic and intent-driven functions for any network of machines. This would avoid the need for new protocols to be defined and implemented on the network elements themselves. Using the same protocol for deployment of network and higher-level services therefore promises more consistent deployment models, and reduced need for ad-hoc signaling solutions at different layers or in different parts of the system. Since basic capabilities such as discovery, signaling, and negotiation are needed in many non-networking scenarios, GRASP also seems a natural candidate for reuse. These kind of infrastructures where multiple administrative domain co-exist are especially encountered by cloud providers, with Autonomic Nodes being servers, end hosts and virtualized or cloud-native infrastructure. In such configuration, routers and other network elements are not always under the control of the same administrator, and do not necessarily include support for GRASP. Such environments where router cooperation is not possible raises issues related to discovery, with Autonomic Nodes being unable to relay their discovery packets outside of the local subnet (ie. through routers). The purpose of this document is to provide a problem statement for such use of GRASP, without cooperation from network elements, also called "GRASP through routers", with a view towards an autonomic cloud. It aims at identifying the technical and operational challenges that arise when GRASP is employed on general-purpose hosts or virtualized infrastructure. The goal is not to specify new mechanisms or profiles, but to offer a clear problem space and terminology and to identify areas where future work on extensions, profiles, or architectural refinements would be useful to effectively apply GRASP outside of its original network-centric context.

Network architecture description This section defines the substrate network architecture that prompts potential new developments for GRASP. The main consideration is the deployment of Autonomic Service Agents across heterogeneous network environments, where protocol support cannot be assumed for all of the devices.

The base subnet: a GRASP-aware environment For the purpose of this document, we define a base subnet as a set of Autonomic Nodes with contiguous support for the GRASP hop-by-hop discovery mechanism. The definition takes from the usually accepted networking definition of a subnet as an array of machines connected to one another, directly or via packet switching, but adding the constraint that within a base subnet as used in this document, support for GRASP is required. Any part of the network not able to be connected to the rest over link-local discovery defines another base subnet. The idea behind this concept is that since link-local connectivity is expected between adjacent nodes within a subnet, any system administrator can independently operate a fully GRASP-aware cluster on a set of nodes within a base subnet without prior network configuration. It should be noted that within this scope, the protocol remains agnostic to the presence of non-participating nodes; any machine not supporting GRASP will simply ignore the traffic and, in turn, be ignored by the protocol.

GRASP domains transcend administrative domains The goal of this document is to address the question of how to create a GRASP bridge between two or more base subnets, each supporting GRASP fully. In the standard GRASP case, this is eased by the fact that boundary routers have support for the protocol itself, which is the key assumption this document aims to break. We therefore assume for the reference network that two base subnets are interconnected by one or more routers, which are by themselves GRASP-unaware. This does not mean that the routers have an explicit policy forbidding them to route GRASP packets, but that they do not have builtin support for GRASP, and cannot by themselves answer any kind of GRASP packet, nor relay them. Such cases can occur when all elements of the network, being them servers, routers or any other computers, reside in different administrative domains, and may be operated by independent providers. Consequently, while some routers (or other networking elements) might support GRASP, such support cannot be enforced on a different administrative domain, and the routing infrastructure may contain networking elements whose firmware is completely unaware of the protocol. A typical example is cloud networks, where services are deployed in complex, multi-region environments, and the client has low to no control over the oftentime numerous networking elements forming the end-to-end path. Even though there are limitations on the support of GRASP within the network, the network itself is mostly consistent with the initial requirements for GRASP, as it provides a viable path between any two nodes. It enables reliable unicast transport, whether facilitated by physical routers, overlay networks, or Virtual Private Networks (VPNs). The only extra assumption is that it is impossible in the general case to guarantee that routers will have a builtin way to relay GRASP messages from one subnet to another, or, in other words, that they will accept to relay from one interface to another. This is the key constraint for GRASP through routers.

An example network architecture for GRASP through routers: since router #2 does not support the GRASP protocol, discovery packets are confined to the boundary of subnets #1 and #2

Additional considerations While the fundamental basis that motivates further work on GRASP can be explained through the use of GRASP-unaware networking devices, there are additional network configurations that may render the use of the protocol easier or harder in some use cases. Some of these additional considerations, relevant to the present document, are described in the present section. One of these networking techniques is the use of address-rewriting, such as Network Address Translation (NAT) . Such techniques are explicitely discouraged as being unsupported in the GRASP reference document, and are mostly unused in practice as far as IPv6 is concerned. This document does not try to address these problems specifically, but some of the suggested solutions may work in such contexts. There might also be cases where some routers support GRASP, and some do not. For the purpose of this document, we call such networks mixed networks. Mixed networks must be supported by all proposed additions in order to keep full compatibility with existing GRASP deployments. These deployments may therefore be extended by potential additions described in this document, but do not need such support to keep working.

Identified challenges This section examines potential issues encountered when using GRASP, at any stage of an Autonomic Node lifecycle, within the network architecture described above. GRASP being built around two distinct mechanisms: discovery and negotiation, both are examined in order to describe protocol usage within the reference network architecture.

Negotiation: a peer-to-peer protocol Negotiation is used by a Autonomic Node to request an objective from another; as such, it is purely an end-to-end procedure, and uses unicast packets. This feature makes the negotiation mechanism work in all possible cases within the described network architecture, since a viable unicast path is always assumed to exist between any two nodes. Similarly, synchronisation, which uses the same mechanism, already works without issues, one notable exception to this rule being synchronization flooding, which is from a networking perspective closer to the discovery mechanism than to negotiation or synchronization, and will be treated as such in this document.

Discovery and flooding: the relaying mechanism While no issue arises from the negotiation procedure, the other GRASP mechanism, discovery (as well as the similar flooding mechanism), used to locate Autonomous Service Agents (ASAs) supporting a given objective, is not as simple. It relies not only on simple unicast, but for many parts requires multicast , as well as a specific protocol for domain-wide flooding through hop-by-hop link-local forwarding between adjacent nodes. Such a behavior should be analyzed in details to understand in which ways it may fail within the described architecture. The core issue is that the discovery mechanism causes domain fragmentation at the boundary of subnets in environment with only partial GRASP support, more specifically when routers at the boundary of a subnet do not have explicit GRASP support. In use cases as described, this reliance on hop-by-hop forwarding creates a fragile discovery topology: in a heterogeneous network where GRASP support is not ubiquitous, a single legacy router or non-compliant switch acts as an barrier to discovery probes. Because link-local multicast is confined to the immediate segment, the discovery mechanism cannot get through non-GRASP nodes and reach other ASAs in the domain. Consequently, messages being confined to a subnet will lead to issues in the deployment of the required range of services. If a DNS server is to be discovered, on a given subnet, using GRASP, machines from all other subnets will fail to autoconfigure, although the DNS server is by itself reachable through routers, and manual configuration would have succeeded. Extending GRASP to support such use case would therefore benefit the development of autonomic networking as a whole, as it extends cases where manual configuration is avoidable. As well as issues related to the passing of messages, the network risks fragmentation into multiple subdomains without explicit division in cases where GRASP messages are blocked at subnet boundaries. Servers residing behind non-participating routers remain invisible to the wider group, and global configuration state distributed via flooding becomes inconsistent across the domain. Without a fallback mechanism or a method to bypass these gaps, the protocol remains hard to use in a global infrastructure.

Mandatory security and the Autonomic Control Plane As defined in the GRASP specification, every solution must specify a security mechanism to be used by GRASP. The main security mechanism, part of the Autonomic Control Plane (ACP) , is dependent on the establishment of an out-of-band hop-by-hop link-local overlay network, which, in itself, cannot work within the described architecture, for the same reasons that the discovery mechanism. Since the security mechanism is not a part of the GRASP specification per se, this document does not aim at improving the ACP further to support use cases described in the network architecture description. It simply emphasizes that such mechanism cannot be used as-is within this architecture, and that new security substrates should be developped, even though standardizing such mechanism may not always be needed, depending on the use case.

Proposed architecture To get GRASP to work within the network architecture, the key challenge is to solve again the issue of relaying packets, which routers are usually reluctant to do, and for which the GRASP hop-by-hop discovery mechanism was created. To avoid any hard assumptions, the suggested architecture takes a base case where the network only supports unicast, refinements being discussed thereafter.

Relay nodes as a solution to the discovery problem An approach to solving the core issue of discovery involves added initial knowledge: to consider the most extreme case, if all nodes knew their peers beforehand, GRASP could unicast discovery packets to each peer every time. This approach is possible within GRASP's bounds, but ends up in a non-reconfigurable network. Instead, initial knowledge can be given to at least one node within each subnet, which will be tasked to relay GRASP messages to other subnets; we call such node a relay node. A relay node has two important parameters: a list of peer nodes and an optional local interface. With such parameters, a relay node's task can be summarized as follows: it listens for incoming multicast or unicast GRASP messages, and reemits these messages both as unicast messages addressed to all peer nodes, and as multicast messages on the local interface, if defined. Peer nodes known by a relay node can be of two kinds: other relay nodes, in which case the relay node proxies part of the router function of forwading multicast to peers, or non-relay nodes, making the relay node an "omniscient" node with great network knowledge.

One relay per subnet The first case described, where relaying is done between relay nodes, relies on having one relay node inside each subnet, which simply needs to be pre-configured with addresses of the other relay nodes within other reachable subnets. A tradeoff to this solution is partial centralization, at the subnet level: if the relay node becomes unreachable, querying other subnets becomes impossible. To send traffic outside of the current subnet, a node therefore acts as in a standard GRASP configuration, by sending traffic multicasted to peers, such peers including the relay node. The flow is pictured in figure , and upon leaving node (1), a packet goes through the relay node, which unicasts it (2) to another relay node within a different subnet, where it gets sent as multicast on the local interface (3). In order to keep things simple, we assume that there is at most one relay node within each subnet. Support for more that one such node could be developped later to introduce redundancy, but it is hard in such case to decide which is responsible for what, and to avoid sending a packet multiple times, creating useless network traffic.

Traffic flow with one relay per subnet

Omniscient relays Having at most one relay per subnet also includes the case of only one relay node globally, as hinted previously: the suggested infrastructure is not restricted to one machine per subnet. Indeed, in simpler architectures, it might not be convenient to have multiple relay nodes, for instance when almost all machines are within their own base subnet. In such cases, a single machine can have discovery knowledge, and know how to address all other nodes within the network. Such a machine would be able to use the same "indirect unicast" mechanism, where a node addresses (over unicast) to a central node, within or outside of the subnet, that node then relaying the GRASP message, also over unicast, to all of the nodes it knows. This goes a level of centralization further compared to the one relay per subnet case, and the relay node would have to get knowledge of the other nodes using an ad-hoc mechanism or pre-configuration. The flow for omniscient relays is simple, and consists of two unicast packets: GRASP packets get sent to the relay node, which unicasts them to all other nodes. To make this configuration work, a mechanism is needed to inhibit the hop-by-hop multicast mechanism from all nodes. Otherwise, packets may be received multiple times if some level of adjacency exists within the network.

Proposed protocol additions The proposed architecture prompts for at least three specific additions to the GRASP protocol: definition of an objective for the relay node, standardization of an algorithm for relaying, and development of a mechanism to inhibit the hop-by-hop multicast mechanism for some nodes. A new relay objective must be defined to enable the automatic discovery of a relay node within a local subnet. Such objective would facilitate zero-configuration deployment, allowing nodes to automatically discover and configure their local relay in cases where there is one relay per subnet. The objective can be used for discovery of relay nodes, as well as for configuration of their main parameters: peers and local interface. For scenarios where there is only one global relay node, it must also be possible to configure such relay manually. On top of defining an objective, one should formally define the precise relay algorithm. An overview of the latter is given in this document, but subtleties will occur, that prompts a full definition of how packets should be forwarded when the hop-by-hop multicast mechanism is disabled. Finally, such way to turn off this mechanism on nodes, when certain conditions are met, once a global relay node has been successfully discovered or manually configured, shall be specified, nodes must be able to suppress multicast discovery and instead route traffic using indirect unicast via the relay. It should be noted that such changes would not replace the traditional GRASP architecture, and will instead be used at the same time. As the definition from this document suggests, a base subnet is a contiguous GRASP-aware set of nodes, and can encompass multiple networking subnets. In other words, a fully GRASP-aware network, no matter how big or complex, only forms one base subnet, and does not need to be aware of the suggested additions.

Operational Considerations TBD

Security Considerations TBD

IANA Considerations This document is informational and has no IANA actions.

Normative References Informative References

Acknowledgments Part of this draft is based on an discussion with , who provided a lot of preliminary ideas. I hope I did not betray the discussion too much while drafting. Also, gave a lot of early guidance before draft submission, for which I am thankful.