| < draft-li-lsr-liveness-02.txt | draft-li-lsr-droid-00.txt > | |||
|---|---|---|---|---|
| LSR Working Group Tony. Li | LSR Working Group T. Li | |||
| Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
| Intended status: Standards Track 3 February 2022 | Intended status: Standards Track 4 April 2022 | |||
| Expires: 7 August 2022 | Expires: 6 October 2022 | |||
| Node Liveness Protocol | Distributed Routing Object Information Database (DROID) | |||
| draft-li-lsr-liveness-02 | draft-li-lsr-droid-00 | |||
| Abstract | Abstract | |||
| Prompt notification of the loss of node liveness or reachability is | Over time, the routing protocols have been burdended with the | |||
| useful for restoring services in tunneled topologies. IGP | responsiblity of carrying a variety of information that is not | |||
| summarization precludes remote nodes from directly observing the | directly relevant to their mission. This includes VPN parameters, | |||
| status of remote nodes. This document proposes a service that, in | configuration information, and capability data. All of the | |||
| conjunction with the IGP, provides prompt notifications without | additional data impacts the performance and stability of the routing | |||
| impacting IGP summarization. | 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. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 7 August 2022. | This Internet-Draft will expire on 6 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Use Case: Node Liveness . . . . . . . . . . . . . . . . . 4 | |||
| 3. Node Liveness Capability Advertisement . . . . . . . . . . . 3 | 1.2. Use Case: Capabilities . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Node Liveness Advertisement in IS-IS . . . . . . . . . . 3 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.2. Node Liveness Advertisement in OSPF . . . . . . . . . . . 5 | 3. DROID Capability Advertisement . . . . . . . . . . . . . . . 5 | |||
| 4. Node Liveness Protocol . . . . . . . . . . . . . . . . . . . 6 | 3.1. DROID Advertisement in IS-IS . . . . . . . . . . . . . . 5 | |||
| 4.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. DROID Advertisement in OSPF . . . . . . . . . . . . . . . 6 | |||
| 4.2. Client actions . . . . . . . . . . . . . . . . . . . . . 6 | 4. DROID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3. ABR actions . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3.1. Autonomous Notification Mode . . . . . . . . . . . . 8 | 4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3.2. Proxy ABRs . . . . . . . . . . . . . . . . . . . . . 8 | 4.3. Object Values . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.4. Registration Messages . . . . . . . . . . . . . . . . . . 8 | 4.4. Client Actions . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.4.1. Liveness Registration sub-TLV . . . . . . . . . . . . 9 | 4.4.1. Client Liveness Actions . . . . . . . . . . . . . . . 8 | |||
| 4.5. Notification Messages . . . . . . . . . . . . . . . . . . 9 | 4.4.2. Client Capability Actions . . . . . . . . . . . . . . 8 | |||
| 4.5.1. Liveness Notification sub-TLV . . . . . . . . . . . . 9 | 4.5. ABR Actions . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 4.5.1. ABR Liveness Actions . . . . . . . . . . . . . . . . 9 | |||
| 5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.5.2. Autonomous Notification Mode . . . . . . . . . . . . 10 | |||
| 5.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.5.3. Proxy ABRs . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 4.6. Publish Messages . . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 | 4.7. Subscribe Messages . . . . . . . . . . . . . . . . . . . 11 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.8. Notification Messages . . . . . . . . . . . . . . . . . . 11 | |||
| 4.9. Message Sub-TLVs . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 4.9.1. Prefix sub-TLV . . . . . . . . . . . . . . . . . . . 12 | ||||
| 4.9.2. Key Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 4.9.3. Object Value Sub-TLV . . . . . . . . . . . . . . . . 13 | ||||
| 4.9.4. Liveness Sub-TLV . . . . . . . . . . . . . . . . . . 13 | ||||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | ||||
| 5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 5.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 5.3. DROID Parameters . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 5.4. DROID Sub-TLV Types Registry . . . . . . . . . . . . . . 14 | ||||
| 5.5. DROID Capability Values Registry . . . . . . . . . . . . 15 | ||||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | ||||
| 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| 1. Introduction | 1. Introduction | |||
| Overlay services are increasingly common and are implemented by | Over time, the routing protocols have been burdended with the | |||
| creating tunnels over a physical infrastructure. The failure of one | responsiblity of carrying a variety of information that is not | |||
| of the tunnel endpoints implies that the traffic towards that | directly relevant to their mission. This includes VPN parameters, | |||
| endpoint will be lost until the other endpoint recognizes the | configuration information, and capability data. All of the | |||
| situation and takes remedial action. Prompt notification of the | additional data impacts the performance and stability of the routing | |||
| failure of the other endpoint is useful in minimizing the duration of | protocols negatively. | |||
| the outage. | ||||
| Some network designs have come to rely on examining the IGP's Link | This has been convenient since the backbone of a routing protocol is | |||
| State Database (LSDB) to determine node liveness and, through the IGP | a small distributed database of routing information. Any service | |||
| SPF computation, the node's reachability. However, if the network is | needing a distributed database has considered injecting its data into | |||
| to scale, some form of summarization must be employed, resulting in | a routing protocol so that it can leverage the protocols database | |||
| this information no longer being directly available. This document | service. Architecturally, this is a mistake that puts the protocol | |||
| proposes a protocol that will provide prompt notificaion of changes | at risk from undue complexity and overhead. | |||
| in node liveness, even in networks that employ IGP summarization. | ||||
| 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 | The service itself runs on OSPF [RFC2328] [RFC5340] Area Border | |||
| Routers (ABRs) or IS-IS [ISO10589] L1-L2 routers. For brevity, we | Routers (ABRs) or IS-IS [ISO10589] L1-L2 routers. For brevity, we | |||
| will use the term 'ABRs' for both cases. | will use the term 'ABRs' for both cases. | |||
| This service uses a simple, hierarchical publish-subscribe | This service uses a simple, hierarchical publish-subscribe | |||
| architecture. Clients are nodes within non-backbone OSPF areas or L1 | architecture. Clients are nodes within non-backbone OSPF areas or L1 | |||
| IS-IS area. They register with their local ABRs. The ABRs are fully | IS-IS area. They subscribe with their local ABRs. The ABRs are | |||
| meshed, with the exception that ABRs of the same area need not | fully meshed, with the exception that ABRs of the same area need not | |||
| interact. Notifications initiated by an ABR flow to other ABRs and | interact. Notifications initiated by an ABR flow to other ABRs and | |||
| from there to client nodes. | from there to client nodes. | |||
| The availability of this service is advertised as part of the IGP, so | The availability of this service is advertised as part of the IGP, so | |||
| that discovery of the service is automatic. Clients can | that discovery of the service is automatic. Clients can | |||
| automatically detect their local ABRs and ABRs can detect each other | automatically detect their local ABRs and ABRs can detect each other | |||
| and automatically form the necessary hierarchy. | and automatically form the necessary hierarchy. | |||
| The protocol runs on top of TCP [RFC0793] and/or QUIC [RFC9000] for | The protocol runs on top of TCP [RFC0793] and/or QUIC [RFC9000] for | |||
| reliability. Security is provided by conventional transport protocol | reliability. Security is provided by conventional transport protocol | |||
| mechanisms, such as TLS [RFC5246]. | mechanisms, such as TLS [RFC5246]. | |||
| 1.1. Use Case: Node Liveness | ||||
| 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 liveness should not be confused with service liveness. If a | |||
| node is alive, then a service may or may not be up. This protocol | node is alive, then a service may or may not be up. This protocol | |||
| only tries to convey node liveness. | only tries to convey node liveness. | |||
| 1.2. Use Case: Capabilities | ||||
| 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. | ||||
| 2. Requirements Language | 2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. Node Liveness Capability Advertisement | 3. DROID Capability Advertisement | |||
| The Node Liveness Protocol is run by ABRs and is advertised in the | DROID itself is run by ABRs and is advertised in the IGP for | |||
| IGP for connections by clients and other ABRs. Advertisements are | connections by clients and other ABRs. Advertisements are done both | |||
| done both into the backbone (L2) and into non-backbone (L1) areas. | into the backbone (L2) and into non-backbone (L1) areas. The | |||
| The advertisements into the backbone allow ABRs to automatically | advertisements into the backbone allow ABRs to automatically mesh. | |||
| mesh. The advertisements into the non-backbone areas allow clients | The advertisements into the non-backbone areas allow clients to | |||
| to automatically determine where the service is available. | automatically determine where the service is available. | |||
| 3.1. Node Liveness Advertisement in IS-IS | 3.1. DROID Advertisement in IS-IS | |||
| An ABR advertises the IS-IS Node Liveness sub-TLV as part of the IS- | An ABR advertises the IS-IS DROID sub-TLV as part of the IS-IS Router | |||
| IS Router Capability TLV [RFC7981]. This is injected into the ABRs | Capability TLV [RFC7981]. This is injected into the ABRs L1 and L2 | |||
| L1 and L2 LSP. The format of the IS-IS Node Liveness sub-TLV is: | LSP. The format of the IS-IS Node Liveness sub-TLV is: | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length |O|N| Reserved | TPI | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Port Number | IPv4 Address | | | Port Number | IPv4 Address | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | IPv4 Address | IPv6 Address... | | | IPv4 Address | IPv6 Address... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 4, line 41 ¶ | skipping to change at page 6, line 9 ¶ | |||
| Port Number: Transport protocol port number, 2 octets | Port Number: Transport protocol port number, 2 octets | |||
| IPv4 Address: Service contact address, 4 octets if the O bit is | IPv4 Address: Service contact address, 4 octets if the O bit is | |||
| set, 0 otherwise. | set, 0 otherwise. | |||
| IPv6 Address: Service contact address, 16 octets if the N bit is | IPv6 Address: Service contact address, 16 octets if the N bit is | |||
| set, 0 otherwise. | set, 0 otherwise. | |||
| The advertisement of this capability indicates that the node is | The advertisement of this capability indicates that the node is | |||
| providing the Node Liveness service on the designated port using the | providing the DROID service on the designated port using the | |||
| designated protocol. The TPI indicates the transport protocol to be | designated protocol. The TPI indicates the transport protocol to be | |||
| used and the Port Number indicates the associated port to be used. | used and the Port Number indicates the associated port to be used. | |||
| The TPI and Port Number pair may be included multiple times to | The TPI and Port Number pair may be included multiple times to | |||
| indicate that multiple protocols and port numbers are available. The | 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 | length of the sub-TLV can be used to determine the number of TPI and | |||
| Port Number pairs. | Port Number pairs. | |||
| An IP address for the ABR MUST be included so that correspondents | 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 | will know how to access the service. An ABR MUST provide an IPv4 | |||
| address, an IPv6 address, or both. | address, an IPv6 address, or both. | |||
| 3.2. Node Liveness Advertisement in OSPF | 3.2. DROID Advertisement in OSPF | |||
| The availabilty of the Node Liveness service is provided by the OSPF | The availabilty of the DROID service is provided by the OSPF Node | |||
| Node Liveness Sub-TLV. The OSPF Node Liveness Sub-TLV is used by | Liveness Sub-TLV. The OSPF Node Liveness Sub-TLV is used by both | |||
| both OSPFv2 and OSPFv3. The semantics are the same as the IS-IS Node | OSPFv2 and OSPFv3. The semantics are the same as the IS-IS Node | |||
| Liveness Sub-TLV. The format of the OSPF Node Liveness Sub-TLV is: | Liveness Sub-TLV. The format of the OSPF DROID Sub-TLV is: | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |O|N| Reserved | TPI | Port Number | | |O|N| Reserved | TPI | Port Number | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | IPv4 Address | | | IPv4 Address | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 5, line 37 ¶ | skipping to change at page 7, line 4 ¶ | |||
| O: 1 if an IPv4 Address is included | O: 1 if an IPv4 Address is included | |||
| N: 1 if an IPv6 Address is included | N: 1 if an IPv6 Address is included | |||
| Reserved: must be zero and ignored on receipt, 6 bits | Reserved: must be zero and ignored on receipt, 6 bits | |||
| TPI: Transport Protocol Identifier, 1 octet | TPI: Transport Protocol Identifier, 1 octet | |||
| 0: TCP | 0: TCP | |||
| 1: QUIC | 1: QUIC | |||
| Port Number: Transport protocol port number, 2 octets | Port Number: Transport protocol port number, 2 octets | |||
| IPv4 Address: Service contact address, 4 octets if the O bit is | IPv4 Address: Service contact address, 4 octets if the O bit is | |||
| set, 0 otherwise. | set, 0 otherwise. | |||
| IPv6 Address: Service contact address, 16 octets if the N bit is | IPv6 Address: Service contact address, 16 octets if the N bit is | |||
| set, 0 otherwise. | set, 0 otherwise. | |||
| The TPI and Port Number fields are used in the same way as for IS-IS. | The TPI and Port Number fields are used in the same way as for IS-IS. | |||
| 4. Node Liveness Protocol | 4. DROID | |||
| 4.1. Messages | 4.1. Messages | |||
| The Node Liveness Protocol sends messages in a stream inside of the | DROID sends messages in a stream inside of the selected transport | |||
| selected transport protocol. The protocol uses two message types: | protocol. The protocol uses three message types: | |||
| Registration Messages and Notification Messages. Each has a sub-TLV | ||||
| to carry specifics about the relevant prefix. | ||||
| 4.2. Client actions | Publish: A node generates a Publish message to change a data value | |||
| in the database. If another node has subscribed to this data | ||||
| item, it will be informed by a Notification message. | ||||
| Subscribe: A Subscribe message creates a subscription for a set of | ||||
| data items. Subsequent updates for the data will generate a | ||||
| corresponding Notification message containing the data items. | ||||
| Notification: A Notification message is generated when a database | ||||
| item is modified. Any nodes that have subscribed to the data item | ||||
| are sent a Notification message with the value of the data item. | ||||
| Each message has sub-TLVs to carry more specific information. | ||||
| 4.2. Keys | ||||
| 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. | ||||
| 4.3. Object Values | ||||
| 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. | ||||
| 4.4. Client Actions | ||||
| The client may determine the set of ABRs that it wishes to | The client may determine the set of ABRs that it wishes to | |||
| communicate with by examination of its LSDB. The client SHOULD open | communicate with by examination of its LSDB. The client SHOULD open | |||
| connections to at least two ABRs for redundancy. If the client | connections to at least two ABRs for redundancy. If the client | |||
| cannot open two connections, then the management system should be | cannot open two connections, then the management system should be | |||
| informed. | informed. | |||
| The client MAY send Registration Messages (with a Liveness | Clients send Subscribe messages to subscribe to particular data that | |||
| Registration sub-TLV) on each of its ABR connections. A client MAY | it would like to receive Notifications about. A client MAY set the G | |||
| register for any number of prefixes, but it is expected that a client | bit in the Subscribe message if it would like to get the current | |||
| will send a registration for each of the tunnel endpoints that it | value of the data as of when it subscribes. | |||
| will correspond with. A client may register for a host (a /32 or | ||||
| /128 prefix) or a shorter prefix. A client MUST NOT send overlapping | ||||
| registrations. | ||||
| Clients never send Notification Messages and never recive | Clients never send Notification messages and never receive Subscribe | |||
| Registration Messages. | messages. The actions of the client on receiving a Notification | |||
| message are out of scope for this document. | ||||
| The actions of the client on receiving a Notification Message are out | 4.4.1. Client Liveness Actions | |||
| of scope for this document. | ||||
| 4.3. ABR actions | 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. | ||||
| 4.4.2. Client Capability Actions | ||||
| 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. | ||||
| 4.5. ABR Actions | ||||
| Each ABR MUST advertise the availability of the Node Liveness service | Each ABR MUST advertise the availability of the Node Liveness service | |||
| into the backbone (L2) area and into any non-backbone (L1) areas. | 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 | Each ABR MUST have a single connection to each other ABR that is part | |||
| of a different non-backbone (L1) area. To prevent duplicate | of a different non-backbone (L1) area. To prevent duplicate | |||
| connections, only one ABR should initiate the connection. For IS-IS, | connections, only one ABR should initiate the connection. For IS-IS, | |||
| the node with the lowest system ID should initiate the connection. | the node with the lowest system ID should initiate the connection. | |||
| For OSPFv4, the node with the lowest IPv4 router ID should initiate | For OSPFv4, the node with the lowest IPv4 router ID should initiate | |||
| the connection. For OSPFv3, the node with the lowest IPv6 router ID | the connection. For OSPFv3, the node with the lowest IPv6 router ID | |||
| should initiate the connection. | should initiate the connection. | |||
| Each ABR may receive Registration Messages, each containing a prefix. | Each ABR may receive Subscribe messages, each containing a prefix. | |||
| These are retained in a Registration Database (RDB) along with its | These are retained in a Subscription Database (SDB) along with its | |||
| associated connection information. If a transport connection closes, | associated connection information. If a transport connection closes, | |||
| then all registrations associated with the connection should be | then all subscriptions associated with the connection should be | |||
| removed from the RDB. If an ABR receives a Registration Message | removed from the SDB. If an ABR receives a Subscription message | |||
| requesting a prefix be unregistered, then the prefix should be | requesting a prefix be unsubscribed, then the prefix should be | |||
| removed from the RDB for that connection. | removed from the SDB for that connection. | |||
| If an ABR receives a Registration Message for a prefix that is being | 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 | injected by a non-attached area, then it SHOULD determine the set of | |||
| ABRs that are advertising that prefix or less specifics and register | ABRs that are advertising that prefix or less specifics and subscribe | |||
| with only those ABRs. The ABR MAY register for the prefix or any of | with only those ABRs. The ABR MAY subscribe for the prefix or any of | |||
| the less specifics. It is RECOMMENDED that the ABR register for the | the less specifics. It is RECOMMENDED that the ABR subscribe for the | |||
| most specific prefix that is less specific than the original prefix. | most specific prefix that is less specific than the original prefix. | |||
| If the ABR cannot find a matching prefix or less specific prefix, | If the ABR cannot find a matching prefix or less specific prefix, | |||
| then the ABR MAY register for all of prefixes that are more specific. | then the ABR MAY subscribe for all of prefixes that are more | |||
| Extreme caution should be used before registering for 0/0. | specific. Extreme caution should be used before subscribing for 0/0. | |||
| If the ABR has registered for a prefix and that prefix is no longer | If the ABR has subscribed for a prefix and that prefix is no longer | |||
| advertised by another ABR then an ABR MAY unregister, re-evaluate its | advertised by another ABR then an ABR MAY unsubscribe, re-evaluate | |||
| registration and register for a different prefix. In this way, if a | its subscription and subscribe for a different prefix. In this way, | |||
| summary prefix changes, the ABR can shift to the new summary prefix. | if a summary prefix changes, the ABR can shift to the new summary | |||
| prefix. | ||||
| An ABR or client SHOULD NOT send duplicate registrations. If an ABR | An ABR or client SHOULD NOT send duplicate subscriptions. If an ABR | |||
| or client is already registered for a prefix, a duplicate | or client is already subscribed for a prefix, a duplicate | |||
| registration SHALL be ignored by the receiving ABR. | 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. | ||||
| 4.5.1. ABR Liveness Actions | ||||
| Each ABR should monitor its IGP LSDB for changes in node liveness. | 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 | 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 | 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 | 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 | Events and Down Events for non-host prefixes are out of scope for | |||
| this document. | this document. | |||
| If an ABR receives a Notification Message with an Up Event for a | 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 | 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 | receives a Notification message with a Down Event for a prefix, then | |||
| it is considered a Down Event for the prefix. | it is considered a Down Event for the prefix. | |||
| If an ABR observes an Up Event for a host, it examines its RDB for | If an ABR observes an Up Event for a host, it examines its SDB for | |||
| registrations for that node or for any less specific prefixes. If | subscriptions for that node or for any less specific prefixes. If | |||
| there are any, then the ABR sends a Notification Message (with a | 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 | Liveness Notification sub-TLV) with an Up Event for that host to each | |||
| node that registered. If there are no registrations, then the event | node that subscribed. If there are no subscriptions, then the event | |||
| MUST be ignored. | MUST be ignored. | |||
| Similarly, if an ABR observes a Down Event for a host, it examines | Similarly, if an ABR observes a Down Event for a host, it examines | |||
| its RDB for registrations for that node or for any less specific | its SDB for subscriptions for that node or for any less specific | |||
| prefixes. If there are any, then the ABR sends a Notification | prefixes. If there are any, then the ABR sends a Notification | |||
| Message (with a Liveness Notification sub-TLV) with a Down Event for | message (with a Liveness Notification sub-TLV) with a Down Event for | |||
| that host to each node that registered. If there are no | that host to each node that subscribed. If there are no | |||
| registrations, then the event MUST be ignored. | subscriptions, then the event MUST be ignored. | |||
| A client may be co-located with an ABR. In other words, an ABR may | ||||
| create registrations for its own purposes. | ||||
| 4.3.1. Autonomous Notification Mode | 4.5.2. Autonomous Notification Mode | |||
| This section describes OPTIONAL ABR behavior. | This section describes OPTIONAL ABR behavior. | |||
| An ABR MAY learn a set of prefixes from its management plane and | An ABR MAY learn a set of prefixes from its management plane and | |||
| enter those prefixes into its RDB. Upon an Up or Down Event for such | 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 | a prefix, the ABR MAY send corresponding notification messages to all | |||
| other ABRs. | other ABRs. | |||
| This may cause ABRs to receive unexpected Notification Messages. | This may cause ABRs to receive unexpected Notification messages. | |||
| Since these do not match client registration messages in its own RDB, | Since these do not match client subscription messages in its own SDB, | |||
| such messages SHALL be ignored. | such messages SHALL be ignored. | |||
| 4.3.2. Proxy ABRs | 4.5.3. Proxy ABRs | |||
| Another node may perform ABR functions instead of the ABR itself. | Another node may perform ABR functions instead of the ABR itself. | |||
| The alternate node is a 'proxy ABR' and performs all of the functions | The alternate node is a 'proxy ABR' and performs all of the functions | |||
| of the ABR with respect to this protocol, except for injecting | of the ABR with respect to this protocol, except for injecting | |||
| capability advertisements into the LSDB. The proxy ABR should listen | capability advertisements into the LSDB. The proxy ABR should listen | |||
| to the IGP within the area so that it can correctly generate | to the IGP within the area so that it can correctly generate | |||
| notifications. One or more ABRs SHOULD advertise the availability of | notifications. The proxy ABR must also listen to the backbone or L2 | |||
| the proxy ABR in its capability advertisements. How the real ABRs | area so that it can locate other ABRs. One or more ABRs SHOULD | |||
| learn about the proxy ABR is out of scope for this document. | 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. | ||||
| 4.4. Registration Messages | 4.6. Publish Messages | |||
| A Registration Message has the following format: | A Publish message has the following format: | |||
| 0 1 2 3 | 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 | 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 |R| Reserved | Sub-TLVs ... | | Type | Length | Sub-TLVs ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: 1 (Registration Message), 1 octet | Type: 1 (Publish message), 1 octet | |||
| Length: length of the sub-TLVs, 2 octets | ||||
| Length: 1 + length of the sub-TLVs, 1 octet | Sub-TLVs: One or more sub-TLVs, specifying the subscription/ | |||
| unsubscription. Variable length. | ||||
| R: 1 bit | 4.7. Subscribe Messages | |||
| 0: Register | A Subscribe message has the following format: | |||
| 1: Unregister | 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 ... | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Reserved: must be zero and ignored on receipt, 7 bits | Type: 2 (Subscribe message), 1 octet | |||
| Sub-TLVs: One or more sub-TLVs, specifying the registration/ | ||||
| unregistration. Variable length. | ||||
| 4.4.1. Liveness Registration sub-TLV | Length: 1 + length of the sub-TLVs, 2 octets | |||
| S: 1 bit | ||||
| 0: Subscribe | ||||
| 1: Unsubscribe | ||||
| G: if set, then the receiver should generate an immediate | ||||
| Notification with the data value(s), 1 bit | ||||
| Reserved: must be zero and ignored on receipt, 6 bits | ||||
| Sub-TLVs: One or more sub-TLVs, specifying the subscription/ | ||||
| unsubscription. Variable length. | ||||
| Use of the G bit for large queries can generate large amounts of | ||||
| data. | ||||
| 4.8. Notification Messages | ||||
| A Notification message has the following format: | ||||
| 0 1 2 3 | 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 | 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 | AFI | | | Type | Length | Sub-TLVs ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Prefix len | Prefix ... | Type: 3 (Notification message), 1 octet | |||
| Length: length of the sub-TLVs, 2 octets | ||||
| Sub-TLVs: One or more sub-TLVs, specifying the subscription and | ||||
| data value(s). Variable length. | ||||
| 4.9. Message 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. | ||||
| 4.9.1. Prefix sub-TLV | ||||
| 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 ... | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: 1 (Registration Message), 1 octet | Type: 1, 1 octet | |||
| Length: 3 + the number of octets for the prefix, 1 octet | Length: 3 + the number of octets for the prefix, 2 octets | |||
| AFI: Address Family Identifier [afireg], 2 octets | AFI: Address Family Identifier [afireg], 2 octets | |||
| Prefix len: number of significant bits in the prefix, 1 octet | Prefix len: number of significant bits in the prefix, 1 octet | |||
| Prefix: The prefix to register/unregister, n octets | Prefix: n octets | |||
| 4.5. Notification Messages | 4.9.2. Key Sub-TLV | |||
| A Notification Message has the following format: | The Key sub-TLV has the format: | |||
| 0 1 2 3 | 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 | 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 ... | | Type | Length | Key .... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: 1 (Registration Message), 1 octet | Type: 2, 1 octet | |||
| Length: length of the sub-TLVs, 1 octet | Length: length of the Key field, in octets, 2 octets | |||
| Key: variable length | ||||
| Sub-TLVs: One or more sub-TLVs, specifying the registration/ | The Key is an opaque variable length list of octets. | |||
| unregistration. Variable length. | ||||
| 4.5.1. Liveness Notification sub-TLV | 4.9.3. Object Value Sub-TLV | |||
| The Liveness Notification sub-TLV has the format: | The Object Value sub-TLV has the format: | |||
| 0 1 2 3 | 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 | 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 | AFI | | | Type | Length | Object Value ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |U| Reserved | Prefix len | Prefix ... | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: 2 (Notification Message), 1 octet | Type: 3, 1 octet | |||
| Length: 3 + number of octets of prefix, 1 octet | Length: length of the Object Value field, in octets, 2 octets | |||
| AFI: Address Family Identifier [afireg], 2 octets | Object Value: variable length | |||
| U: 1 bit | The Object Value is an opaque variable length list of octets. | |||
| 0: Up Event | The Object Value sub-TLV should never appear in a Subscribe message. | |||
| 1: Down Event | 4.9.4. Liveness Sub-TLV | |||
| Reserved: must be zero and ignored on receipt, 7 bits | The Liveness sub-TLV has the format: | |||
| Prefix len: number of significant bits in the prefix, 1 octet | 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 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Prefix: The prefix generating the notification, n octets | Type: 128, 1 octet | |||
| 5. IANA Considerations | Length: 1, 2 octets | |||
| U: Up event, 1 bit | ||||
| D: Down event, 1 bit | ||||
| Reserved: must be zero and ignored on receipt, 6 bits | ||||
| Up events and Down events MAY be subscribed independently or jointly. | ||||
| 5. IANA Considerations | ||||
| 5.1. IS-IS | 5.1. IS-IS | |||
| This document requests the following code points from the "IS-IS Sub- | This document requests the following code points from the "IS-IS Sub- | |||
| TLVs for IS-IS Router CAPABILITY TLV" registry. | TLVs for IS-IS Router CAPABILITY TLV" registry. | |||
| Type: TBD 1 | Type: TBD 1 | |||
| Description: IS-IS Node Liveness sub-TLV | Description: IS-IS Node Liveness sub-TLV | |||
| Reference: This document | Reference: This document | |||
| skipping to change at page 11, line 4 ¶ | skipping to change at page 14, line 23 ¶ | |||
| Reference: This document | Reference: This document | |||
| 5.2. OSPF | 5.2. OSPF | |||
| This document requests the following code points from the "OSPF | This document requests the following code points from the "OSPF | |||
| Router Information (RI) TLVs" registry: | Router Information (RI) TLVs" registry: | |||
| Type: TBD 2 | Type: TBD 2 | |||
| Description: OSPF Node Liveness Sub-TLV | Description: OSPF Node Liveness Sub-TLV | |||
| Reference: This document | Reference: This document | |||
| 5.3. DROID Parameters | ||||
| 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. | ||||
| 5.4. DROID Sub-TLV Types Registry | ||||
| 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 | | ||||
| +-------+----------------------+ | ||||
| Table 1 | ||||
| 5.5. DROID Capability Values Registry | ||||
| 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. | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| This document creates no new security issues. Security of transport | Security of transport protocol connections are addressed by the use | |||
| protocol connections are addressed by the use of conventional | of conventional transport protocol security techniques, such as TLS. | |||
| transport protocol security techniques, such as TLS. IGP | IGP advertisements are not expected to have privacy, so the | |||
| advertisements are not expected to have privacy, so the advertisement | advertisement of the service is not a security issue. | |||
| of the service is not a security issue. | ||||
| Authentication is an outstanding issue, to be handled in a future | ||||
| version of this document. | ||||
| 7. Normative References | 7. Normative References | |||
| [afireg] IANA, "Address Family Numbers", November 1988, | [afireg] IANA, "Address Family Numbers", November 1988, | |||
| <https://www.iana.org/assignments/address-family-numbers/ | <https://www.iana.org/assignments/address-family-numbers/ | |||
| address-family-numbers.xhtml#address-family-numbers-2>. | address-family-numbers.xhtml#address-family-numbers-2>. | |||
| [ISO10589] ISO, "Intermediate system to Intermediate system routing | [ISO10589] ISO, "Intermediate system to Intermediate system routing | |||
| information exchange protocol for use in conjunction with | information exchange protocol for use in conjunction with | |||
| the Protocol for providing the Connectionless-mode Network | the Protocol for providing the Connectionless-mode Network | |||
| skipping to change at page 12, line 16 ¶ | skipping to change at page 16, line 48 ¶ | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
| DOI 10.17487/RFC9000, May 2021, | DOI 10.17487/RFC9000, May 2021, | |||
| <https://www.rfc-editor.org/info/rfc9000>. | <https://www.rfc-editor.org/info/rfc9000>. | |||
| Author's Address | Author's Address | |||
| Tony Li, | Tony Li | |||
| Juniper Networks | Juniper Networks | |||
| 1133 Innovation Way | 1133 Innovation Way | |||
| Sunnyvale, California 94089 | Sunnyvale, California 94089 | |||
| United States of America | United States of America | |||
| Email: tony.li@tony.li | Email: tony.li@tony.li | |||
| End of changes. 84 change blocks. | ||||
| 171 lines changed or deleted | 394 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||