| Internet-Draft | DROID | April 2022 |
| Li | Expires 6 October 2022 | [Page] |
Over time, the routing protocols have been burdended with the responsiblity of carrying a variety of information that is not directly relevant to their mission. This includes VPN parameters, configuration information, and capability data. All of the additional data impacts the performance and stability of the routing protocols negatively.¶
This has been convenient since the backbone of a routing protocol is a small distributed database of routing information. Any service needing a distributed database has considered injecting its data into a routing protocol so that it can leverage the protocols database service. Architecturally, this is a mistake that puts the protocol at risk from undue complexity and overhead.¶
To avoid this, DROID is a subsystem that is tangential to, but independent of the routing protocols, and provides distributed database services for other routing services. It is based on the publish-subscribe (pub/sub) architecture and is intentionally crafted to be an open mechanism for the transport of ancillary data.¶
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 6 October 2022.¶
Copyright (c) 2022 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.¶
Over time, the routing protocols have been burdended with the responsiblity of carrying a variety of information that is not directly relevant to their mission. This includes VPN parameters, configuration information, and capability data. All of the additional data impacts the performance and stability of the routing protocols negatively.¶
This has been convenient since the backbone of a routing protocol is a small distributed database of routing information. Any service needing a distributed database has considered injecting its data into a routing protocol so that it can leverage the protocols database service. Architecturally, this is a mistake that puts the protocol at risk from undue complexity and overhead.¶
To avoid this, DROID is a subsystem that is tangential to, but independent of the routing protocols, and provides distributed database services for other routing services. It is based on the publish-subscribe (pub/sub) architecture and is intentionally crafted to be an open mechanism for the transport of ancillary data.¶
The service itself runs on OSPF [RFC2328] [RFC5340] Area Border Routers (ABRs) or IS-IS [ISO10589] L1-L2 routers. For brevity, we will use the term 'ABRs' for both cases.¶
This service uses a simple, hierarchical publish-subscribe architecture. Clients are nodes within non-backbone OSPF areas or L1 IS-IS area. They subscribe with their local ABRs. The ABRs are fully meshed, with the exception that ABRs of the same area need not interact. Notifications initiated by an ABR flow to other ABRs and from there to client nodes.¶
The availability of this service is advertised as part of the IGP, so that discovery of the service is automatic. Clients can automatically detect their local ABRs and ABRs can detect each other and automatically form the necessary hierarchy.¶
The protocol runs on top of TCP [RFC0793] and/or QUIC [RFC9000] for reliability. Security is provided by conventional transport protocol mechanisms, such as TLS [RFC5246].¶
Overlay services are increasingly common and are implemented by creating tunnels over a physical infrastructure. The failure of one of the tunnel endpoints implies that the traffic towards that endpoint will be lost until the other endpoint recognizes the situation and takes remedial action. Prompt notification of the failure of the other endpoint is useful in minimizing the duration of the outage.¶
Some network designs have come to rely on examining the IGP's Link State Database (LSDB) to determine node liveness and, through the IGP SPF computation, the node's reachability. However, if the network is to scale, some form of summarization must be employed, resulting in this information no longer being directly available. DROID can address this need by combining its distributed database capabilities with the ability to infer knowledge learned from the IGP.¶
Node liveness should not be confused with service liveness. If a node is alive, then a service may or may not be up. This protocol only tries to convey node liveness.¶
Different nodes in the network have different capabilities. Other nodes need to know what these capabilities are for a variety of purposes. The management plane could learn and distribute this information, but asking all nodes to retain all of this information is not efficient. Rather, this information should be made available to the nodes that need the information, when they need it.¶
Capability information has been carried in the IGP frequently, but when the capabilities are not directly related to the IGP, it is an overuse of the IGP itself. This would be a good application of DROID. Each node should be able to advertise its capabilities into DROID. Interested nodes should be able to request capability information from DROID about any node in the network.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
DROID itself is run by ABRs and is advertised in the IGP for connections by clients and other ABRs. Advertisements are done both into the backbone (L2) and into non-backbone (L1) areas. The advertisements into the backbone allow ABRs to automatically mesh. The advertisements into the non-backbone areas allow clients to automatically determine where the service is available.¶
An ABR advertises the IS-IS DROID sub-TLV as part of the IS-IS Router Capability TLV [RFC7981]. This is injected into the ABRs L1 and L2 LSP. The format of the IS-IS Node Liveness sub-TLV is:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |O|N| Reserved | TPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | IPv6 Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
TPI: Transport Protocol Identifier, 1 octet¶
The advertisement of this capability indicates that the node is providing the DROID service on the designated port using the designated protocol. The TPI indicates the transport protocol to be used and the Port Number indicates the associated port to be used. The TPI and Port Number pair may be included multiple times to indicate that multiple protocols and port numbers are available. The length of the sub-TLV can be used to determine the number of TPI and Port Number pairs.¶
An IP address for the ABR MUST be included so that correspondents will know how to access the service. An ABR MUST provide an IPv4 address, an IPv6 address, or both.¶
The availabilty of the DROID service is provided by the OSPF Node Liveness Sub-TLV. The OSPF Node Liveness Sub-TLV is used by both OSPFv2 and OSPFv3. The semantics are the same as the IS-IS Node Liveness Sub-TLV. The format of the OSPF DROID Sub-TLV is:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|N| Reserved | TPI | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
TPI: Transport Protocol Identifier, 1 octet¶
The TPI and Port Number fields are used in the same way as for IS-IS.¶
DROID sends messages in a stream inside of the selected transport protocol. The protocol uses three message types:¶
Each message has sub-TLVs to carry more specific information.¶
Each item in the database must have a key. The key space is hierarchical and variable length. Traditionally, keys have been an ASCII string, with levels in the hierarchy separated by the '/' character, but this is extremely ineffcient. A hierarchical binary key would be more efficient but is harder to manage.¶
Definition of the key space is out of scope for this document.¶
An object in the database is an opaque, variable length string of octets. The interpretation of an object value is outside of the scope of this document.¶
The client may determine the set of ABRs that it wishes to communicate with by examination of its LSDB. The client SHOULD open connections to at least two ABRs for redundancy. If the client cannot open two connections, then the management system should be informed.¶
Clients send Subscribe messages to subscribe to particular data that it would like to receive Notifications about. A client MAY set the G bit in the Subscribe message if it would like to get the current value of the data as of when it subscribes.¶
Clients never send Notification messages and never receive Subscribe messages. The actions of the client on receiving a Notification message are out of scope for this document.¶
The client MAY send Subscribe messages (with a Liveness Subscribe sub-TLV) on each of its ABR connections. A client MAY subscribe for any number of prefixes, but it is expected that a client will send a subscription for each of the tunnel endpoints that it will correspond with. A client may subscribe for a host (a /32 or /128 prefix) or a shorter prefix.¶
A client MAY send Publish messages to advertise its own capabilities. A client MAY send Subscribe messages to subscribe for capabilities of other nodes.¶
There are no special mechanisms to support client capabilities. This is simply a straightforward example of DROID mechanisms.¶
Each ABR MUST advertise the availability of the Node Liveness service into the backbone (L2) area and into any non-backbone (L1) areas.¶
Each ABR MUST have a single connection to each other ABR that is part of a different non-backbone (L1) area. To prevent duplicate connections, only one ABR should initiate the connection. For IS-IS, the node with the lowest system ID should initiate the connection. For OSPFv4, the node with the lowest IPv4 router ID should initiate the connection. For OSPFv3, the node with the lowest IPv6 router ID should initiate the connection.¶
Each ABR may receive Subscribe messages, each containing a prefix. These are retained in a Subscription Database (SDB) along with its associated connection information. If a transport connection closes, then all subscriptions associated with the connection should be removed from the SDB. If an ABR receives a Subscription message requesting a prefix be unsubscribed, then the prefix should be removed from the SDB for that connection.¶
If an ABR receives a Subscribe message for a prefix that is being injected by a non-attached area, then it SHOULD determine the set of ABRs that are advertising that prefix or less specifics and subscribe with only those ABRs. The ABR MAY subscribe for the prefix or any of the less specifics. It is RECOMMENDED that the ABR subscribe for the most specific prefix that is less specific than the original prefix. If the ABR cannot find a matching prefix or less specific prefix, then the ABR MAY subscribe for all of prefixes that are more specific. Extreme caution should be used before subscribing for 0/0.¶
If the ABR has subscribed for a prefix and that prefix is no longer advertised by another ABR then an ABR MAY unsubscribe, re-evaluate its subscription and subscribe for a different prefix. In this way, if a summary prefix changes, the ABR can shift to the new summary prefix.¶
An ABR or client SHOULD NOT send duplicate subscriptions. If an ABR or client is already subscribed for a prefix, a duplicate subscription MUST NOT create a duplicate entry in the SDB.¶
A client may be co-located with an ABR. In other words, an ABR may create subscriptions for its own purposes.¶
Each ABR should monitor its IGP LSDB for changes in node liveness. If an ABR sees an addition to the LSDB, then it is considered an Up Event for that node. If an ABR sees a LSP/LSA time out or become unreachable, then it is considered a Down Event for that node. Up Events and Down Events for non-host prefixes are out of scope for this document.¶
If an ABR receives a Notification message with an Up Event for a prefix, then it is considered an Up Event for the prefix. If an ABR receives a Notification message with a Down Event for a prefix, then it is considered a Down Event for the prefix.¶
If an ABR observes an Up Event for a host, it examines its SDB for subscriptions for that node or for any less specific prefixes. If there are any, then the ABR sends a Notification message (with a Liveness Notification sub-TLV) with an Up Event for that host to each node that subscribed. If there are no subscriptions, then the event MUST be ignored.¶
Similarly, if an ABR observes a Down Event for a host, it examines its SDB for subscriptions for that node or for any less specific prefixes. If there are any, then the ABR sends a Notification message (with a Liveness Notification sub-TLV) with a Down Event for that host to each node that subscribed. If there are no subscriptions, then the event MUST be ignored.¶
This section describes OPTIONAL ABR behavior.¶
An ABR MAY learn a set of prefixes from its management plane and enter those prefixes into its SDB. Upon an Up or Down Event for such a prefix, the ABR MAY send corresponding notification messages to all other ABRs.¶
This may cause ABRs to receive unexpected Notification messages. Since these do not match client subscription messages in its own SDB, such messages SHALL be ignored.¶
Another node may perform ABR functions instead of the ABR itself. The alternate node is a 'proxy ABR' and performs all of the functions of the ABR with respect to this protocol, except for injecting capability advertisements into the LSDB. The proxy ABR should listen to the IGP within the area so that it can correctly generate notifications. The proxy ABR must also listen to the backbone or L2 area so that it can locate other ABRs. One or more ABRs SHOULD advertise the availability of the proxy ABR in its capability advertisements. How the real ABRs learn about the proxy ABR is out of scope for this document.¶
A Publish message has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
A Subscribe message has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
S: 1 bit¶
Use of the G bit for large queries can generate large amounts of data.¶
A Notification message has the following format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The following sub-TLVs may be used with any of the messages above. Multiple sub-TLVs are expected to be used in combination to qualify the containing message. Type codes for DROID Sub-TLVs are allocated from the "DROID Sub-TLV Types" registry, defined below.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The Key sub-TLV has the format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Key .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The Key is an opaque variable length list of octets.¶
The Object Value sub-TLV has the format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Object Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The Object Value is an opaque variable length list of octets.¶
The Object Value sub-TLV should never appear in a Subscribe message.¶
The Liveness sub-TLV has the format:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |U|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Up events and Down events MAY be subscribed independently or jointly.¶
This document requests the following code points from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry.¶
This document requests the following code points from the "OSPF Router Information (RI) TLVs" registry:¶
This document requests that IANA create a new Protocol Registry for "DROID Parameters". The initial contents are the "DROID Sub-TLV Types Registry" and the "DROID Capability Values Registry" defined below.¶
This document requests that IANA create a new registry called the "DROID Sub-TLV Types" registry under the "DROID Parameters" protocol registry. For this registry, the registration procedure is "Standards Action". The range of available numeric values is 0-255. Generic sub-TLVs should be allocated from the range of 0-127. Data specific sub-TLVs should be allocated from the range 128-255. The fields in this registry are a "Value" and a "Name". The initial contents of this registry should be:¶
| Value | Name |
| 1 | Prefix sub-TLV |
| 2 | Key sub-TLV |
| 3 | Object Value sub-TLV |
| 128 | Liveness sub-TLV |
This document requests that IANA create a new registry called the "DROID Capability Values" registry under the "DROID Parameters" protocol registry. For this registry, the registration procedure is "Standards Action". The range of available numeric values is 0-255. There are no initial contents. The fields in this registry are a "Value" and a "Name".¶
Values in this registry should be allocated in increasing order, starting with zero.¶
Each value in this registry corresponds to a bit position within the Capabilities field of the Capabilities sub-TLV. Value 0 indicates the most significant bit of the first octet, with subsequent values indicating bits of decreasing signficance and then subsequent octets, starting with the most significant bit. Thus, value 8 would correspond to the most signficant bit of the second octet.¶
Security of transport protocol connections are addressed by the use of conventional transport protocol security techniques, such as TLS. IGP advertisements are not expected to have privacy, so the advertisement of the service is not a security issue.¶
Authentication is an outstanding issue, to be handled in a future version of this document.¶