Advertising Router Information

Introduction describes a scenario where better load-balancing can be achieved in a CLOS network by considering the load information on the next hop router in addition to considering the local load information of the path to that next hop router. describes another scenario where link up/down information propagated via non-IGP mechanism can help with faster reroute. describes a framework for Adaptive Routing which dynamically adjusts routing paths based on changes in global network conditions, thereby optimizing network performance and resource utilization. To achieve that, a router needs to advertise some link/path information independently of IGP. This document specifies a mechanism to do that. It can also be used to advertise any information. As described in , in a CLOS network the advertisement only needs to be "link-local", i.e., a receiving router does not need to re-advertise it further and the mechanism in this document does not consider re-advertisement. In an arbitrary topology, to achieve coordinated load-balancing the information may need to be advertised further but that is outside the scope of this document. In some scenarios, a large amount of information may need to be advertised, and in some scenarios, the receiving router may not need to be directly connected. While an IGP, if used for the CLOS network, may also be used to advertise the information using link-local flooding scope, it may not be a good fit when the information needs to be advertised and processed very rapidly not for routing purposes. Therefore, UDP is chosen as the transport mechanism. An implementation may advertise and process the UDP messages in the forwarding path for timely responses. This document does not suggest or restrict when and/or how frequently the information is advertised - it is an operational consideration on how frequent the advertisements need to be and whether the routers can handle that. Fragmentation may be used if the delay related to the fragmentation/reassembly is not a concern. Multiple UDP messages may be used to advertise pieces of all the information, whether fragmentation is used or not. This document/revision only specifies the message format. How the information is maintained and used on the receiving router are outside the scope of this document/revision but may be added in future revisions. 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 when, and only when, they appear in all capitals, as shown here.

Specification The message format is defined as follows:

The IP destination address in the outer IP header is typically an IPv4 "All Routers on this Subnet" multicast address (referred to as a link-local multicast address), an IPv6 Node-local All Routers Address (multicast) , a non-link/node-local multicast address, or a local/remote unicast address discovered by means outside the scope of this document. The 4-bit Version field is for potential future extensions that cannot be achieved through additional TLV types. The current version is 0. The four R-bits are reserved - they MUST be 0 upon transmission and MUST be ignored upon receiving. The 1-octet Flags field currently has one A-flag defined. If it is set, the (Auth Type, Auth Len, Auth Data) tuple immediately follows the Flags field. If it is not set, the tuple is not present. The details of the tuple are as specified in and not repeated here. When the flooding happens on a local link, the Link ID field identified the flooding link. The value could be one of the following: An IPv4 interface address advertised by OSPFv2/ISIS An Interface ID advertised by OSPFv3 , or by OSPFv2 for an unnumbered interface A Link Local Identifier advertised by OSPFv2/ISIS for GMPLS In this case, the destination address MUST be a link/node-local multicast address or a receiver's unicast address on the local link and the TTL MUST be 1. The source address MUST be the local interface address for a numbered interface, or a loopback address in case of an unnumbered interface. If the flooding is to one or more remote receivers, the Link ID MUST be set to 0, the destination address MUST be a remote unicast/multicast address, the source address MUST be a loopback address, and the TTL MUST be set to 255, following the Generalized TTL Security Mechanism (GTSM) . The following TLVs are defined to allow maximum packing. If additional information needs to be advertised, new TLVs may be defined without using sub-TLVs to allow efficient encoding of additional information, or with sub-TLVs to allow flexibility but at the cost of processing complexity.

Neighbor Path Information This TLV is used when the path information is at per-neighbor level.

The Length field is two-octet. The Value part starts with a one-octet Refresh Rate field, which is followed by repeated per-Neighbor Records. The number of records is derived from the Length field. The Refresh Rate field's leftmost bit S denotes the unit of the rate. If it is set, the rate is in deciseconds (100ms). If it is not set, the rate is in milliseconds. The per-Neighbor record has the following format:

Neighbor ID: The 4-octet Neighbor ID identifies (the path to) a neighbor that is discovered by means outside the scope of this document. It MAY be a BGP-ID described in or some other identifiers that are unique in the domain where the signaling is used. The neighbor can be reached via ECMP, e.g., a set of links but the nature is outside the scope of this document. encoded info: The 1-octet field following the 4-octet Neighbor ID field which encodes the information of the path to the neighbor.The following encoded info are defined:

Link Information This TLV is used when the information is at per-link level.

The value part is repeated records of the following. The number of records is derived from the Length field.

The Link ID is as described earlier. encoded info: The 1-octet field following the 4-octet Link ID field which encodes the information of the link. It is encoded exactly the same as in the neighbor case.

Refreshing and Aging The sender MUST re-advertise the information when there is a change, and MUST re-fresh previous advertisements at the advertised Refresh Rate even when there is no change. The receiver MUST age out the received information if it does not receive a refresh within a period of three times of the refresh rate. Each time an advertisement for a neighbor is received, the aging timer is reset according to the latest Refresh Rate. The sender MAY adjust the Refresh Rate on its own or based on notification from a receiver (). For example, if the information does not change often, a sender may move to a larger (slower) Refresh Rate. The aging, refreshing and adjustment of the refresh rate are all at the per-neighbor/link level. Neighbors/links whose Refresh Rates are the same SHOULD be packed in the same TLV, but MAY be put into different TLVs and messages due to MTU limitations and/or fragmentation concerns. Neighbors/links whose Refresh Rates are different MUST be put into different TLVs. The same information MAY be sent out of different links or to different set of receivers with different rates.

Refresh Rate Negotiation A receiver SHOULD send notifications to the sender if it can not keep up with the sender, using a Notification TLV of Type 4:

The Value part includes sub-TLVs, whose Types share the same space as the top level TLVs. When sending a notification to a remote node or from an unnumbered interface, a loopback address MUST be used as the source address. Otherwise, the local interface address SHOULD be used as the source address. The destination address MUST be set to the source address in the received flooding packet for which the notification is. To notify the sender the desired Refresh Rate for a certain advertisement, the corresponding TLV (e.g., the Neighbor Path Information TLV) is included as a sub-TLV, and no per-Neighbor/Link records are included. The Refresh Rate field along with the S-flag are set to indicate the desired rate. The Length of the sub-TLV is set accordingly. Other types of TLVs, e.g., this type-4 "Refresh Rate Notification" TLV itself, MUST NOT be included as sub-TLVs. While a typical physical link is point-to-point even in the Ethernet case, there may be multiple receivers of an advertisement sent out of a link (e.g., in the case of LAN) or sent to a group of remote receivers via multicast. If multiple notifications of Refresh Rate are received for an advertisement, the largest requested rate MUST be used by the sender. Consider that a router advertises to a link the information about some neighbor/link set S1 at rate R1 and the information about some other neighbor/link set S2 at rate R2 where R1 < R2, i.e., the S2 information is advertised less frequently. A receiver on the link sends back a notification with rate R3 where R1 < R3 < R2. Then this router MUST use R3 as the refresh rate for S1 and R2 as the refresh rate for S2.

Flow Redirection It may be desired for a router to request its upstream to redirect a specific flow away from it. This is done via Flow Redirection TLV:

The Type is 6 for IPv4 flows or 7 for IPv6 flows. The Value field encodes one or more 5-tuple records that identify flows by (Protocol, Source Address, Destination Address, Source Port, Destination Port). The number of records is derived from the Type and Length fields.

Security Considerations Because the information may be flooded rapidly, potential Denial Of Service (DOS) attack may happen. In the case of local flooding only, the attack needs to happen from within the network, and in that case, other attacks may happen as well and may be worse. In the case of remote flooding, GTSM and ingress filtering at the network boundary are used to reduce the risk. Overall, this is expected to be used in a secure walled-garden network.

IANA Considerations This document requests IANA to allocate a UDP port number TBD1 from the User Ports range of the Service Name and Transport Protocol Port Number Registry. This document requests IANA to create a Router Information TLV Type registry with the following initial allocations:

Acknowledgments The authors thank Jeffrey Haas and Michal Styszynski for their review, comments and suggestions to make this document and solution more complete.