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. 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 transission 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 an appropriate value to ensure its delivery. The security consideration will be added in a future revision of this document. If the Sequence Number is zero, no acknowledgment is needed. If it is not zero, an acknowledgment is requested (). 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:

The 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. The 1-octet field following the 4-octet Neighbor ID field encodes the information of the path to the neighbor. In this revision, only the value 0 is specified, indicating that the path is down. Other values may be specified in future revisions for other information.

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. The 1-octet field following the Link ID field encodes the information of the link. In this revision, only the value 0 is specified, indicating that the path is down. Other values may be specified in future revisions for other information.

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, unless an acknowledgment is requested and received. When acknowledgment is not used, 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. 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.

Acknowledgment For a message flooded on a LAN or to a remote multicast address, its acknowledgment is for further study and may be specified in a future revision. If a received flooding has a non-zero Sequence Number, an acknowledgment MUST be sent. An acknowledgment is a TLV with the following format:

If the message which the acknowledgment is for has a link-local unicast/multicast destination address on a numbered interface, the source IP address of the acknowledgment message (that includes the Acknowledgment TLV) MUST be set to the local address of the interface. Otherwise, it is MUST be set to a loopback address of the acknowledgment sender. The destination address of the acknowledgment MUST be set to the source address in the received message which the acknowledgment is for.

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.