Juniper Networks

tony.li@tony.li

IS-IS MPLKS Segmenting routing Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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.

Table of Contents

• .  Introduction
  • .  Related Work
  • .  Terms and Abbreviations
• .  Overview
  • .  Topological Considerations
  • .  Link Changes
  • .  Scalability
  • .  Assumptions
    • .  Traffic Patterns
    • .  User Station Constraints
    • .  Stochastic Connectivity
  • .  Problem Statement
• .  Forwarding Plane
• .  IGP Suitability and Scalability
• .  Stripes and Areas
• .  Traffic Forwarding and Traffic Engineering
• .  Scheduling
• .  Future Work
• .  Deployment Considerations
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Author's Address

Introduction Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes. Large-scale satellite networks are being deployed, presenting an unforeseen application for conventional routing protocols. The high rate of intentional topological change and the extreme scale are unprecedented in terrestrial networking. Links between satellites can utilize free-space optics technology that allows liberal connectivity. Still, there are limitations due to the range of the links and conjunction with the sun, resulting in links that are far less reliable than network designers are used to. In addition, links can change their endpoints dynamically, resulting in structural changes to the topology. Current satellite networks are proprietary, and little information is generally available for analysis and discussion. This document is based on what is currently accessible. This document proposes one approach to provide a routing architecture for such networks utilizing current standards-based routing technology and to provide a solution for the scalability of the network while incorporating the rapid rate of topological change. This document intends to provide some initial guidance for satellite network operators, but without specific details, this document can only provide the basis for a more complete analysis and design. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.

Related Work A survey of related work can be found in . Link-state routing for satellite networks has been considered in and .

Terms and Abbreviations

Constellation:

A set of satellites.

Downlink:

The half of a ground link leading from a satellite to an Earth station.

Earth station:

A node in the network that is on or close to the planetary surface and has a link to a satellite. This includes ships, aircraft, and other vehicles below LEO .

Gateway:

An Earth station that participates in the network and acts as the interconnect between satellite constellations and the planetary network. Gateways have a much higher bandwidth than user stations, have ample computing capabilities, and perform traffic engineering duties, subsuming the functionality of a network controller or Path Computation Element (PCE) . Multiple gateways are assumed to exist, and each serves a portion of the network.

GEO:

Geostationary Earth Orbit. A satellite in GEO has an orbit that is synchronized to planetary rotation, so it effectively sits over one spot on the planet.

Ground link:

A link between a satellite and an Earth station, composed of a downlink and an uplink.

IGP:

Interior Gateway Protocol. A routing protocol that is used within a single administrative domain. Note that 'gateway' in this context is semantically equivalent to 'router' and has no relationship to the 'gateway' used in the rest of this document.

IS-IS:

Intermediate System to Intermediate System. An IGP that is commonly used by service providers .

ISL:

Inter-Satellite Link. Frequently implemented with free-space optics that allow signaling using photons without any intervening medium .

L1:

IS-IS Level 1

L1L2:

IS-IS Level 1 and Level 2

L2:

IS-IS Level 2

LEO:

Low Earth Orbit. A satellite in LEO has an altitude of 2,000 km or less.

Local gateway:

Each user station is associated with a single gateway in its region.

LSP:

Link State Protocol Data Unit. An IS-IS LSP is a set of packets that describe a node's connectivity to other nodes.

MEO:

Medium Earth Orbit. A satellite in MEO is between LEO and GEO and has an altitude between 2,000 km and 35,786 km.

SID:

Segment Identifier

Stripe:

A set of satellites in a few adjacent orbits. These form an IS-IS L1 area.

SR:

Segment Routing

Uplink:

The half of a link leading from an Earth station to a satellite.

User station:

An Earth station interconnected with a small end-user network.

Overview

Topological Considerations Satellites travel in specific orbits around their parent planets. Some of them have their orbital periods synchronized to planetary rotation, so they are effectively stationary over a single point. Other satellites have orbits that cause them to travel across regions of the planet either gradually or quite rapidly. Respectively, these are typically known as the Geostationary Earth Orbit (GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on the altitude. This discussion is not Earth-specific; as we get to other planets, we can test this approach's generality. Satellites may have data interconnections with one another through Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may be connected temporarily with periods of potential connectivity computed through orbital dynamics. Multiple satellites may be in the same orbit but separated in space with a roughly constant separation. Satellites in the same orbit may have ISLs that have a higher duty cycle than ISLs between different orbits, but they are still not guaranteed to be always connected.

Overall Network Architecture User +-----------------+ Local Stations --- | Satellites |--- Gateway --- Internet +-----------------+

Earth stations can communicate with one or more satellites in their region. User stations are Earth stations with a limited capacity that communicate with only a single satellite at a time. Other Earth stations that may have richer connectivity and higher bandwidth are commonly called "gateways" and provide connectivity between the satellite network and conventional wired networks. Gateways serve user stations in their geographic proximity and are replicated globally as necessary to provide coverage and to meet service density goals. User stations are associated with a single local gateway. Traffic from one Earth station to another may need to traverse a path across multiple satellites via ISLs.

Link Changes Like conventional network links, ISLs and ground links can fail without warning. However, unlike terrestrial links, there are predictable times when ISLs and ground links can potentially connect and disconnect. These predictions can be computed and cataloged in a schedule that can be distributed to relevant network elements. Predictions of a link connecting are not guaranteed: A link may not connect for many reasons. Link disconnection predictions due to orbital dynamics are effectively guaranteed, as the underlying physics will not improve unexpectedly.

Scalability Some proposed satellite networks are fairly large, with tens of thousands of proposed satellites . A key concern is the ability to reach this scale and larger, as useful networks tend to grow. As we know, the key to scalability is the ability to create hierarchical abstractions, so a key question of any routing architecture will be about the abstractions that can be created to contain topological information. Normal routing protocols are architected to operate with a static but somewhat unreliable topology. Satellite networks lack the static organization of terrestrial networks, so normal architectural practices for scalability may not apply, and alternative approaches may need consideration. In a typical deployment of a link-state routing protocol, current implementations can be deployed with a single area that spans a few thousand routers. A single area would also provide no isolation for topological changes, causing every link change to be propagated throughout the entire network. This would be insufficient for the needs of large satellite networks. Multiple areas or multiple instances of an Interior Gateway Protocol (IGP) can be used to improve scalability, but there are limitations to typical approaches. Currently, the IETF actively supports two link-state IGPs: OSPF and IS-IS. OSPF requires that the network operate around a backbone area, with subsidiary areas hanging off of the backbone. While this works well for typical terrestrial networks, this does not seem appropriate for satellite networks, where there is no centralized portion of the topology. IS-IS has a different hierarchical structure, where Level 1 (L1) areas are connected sets of nodes, and then Level 2 (L2) is a connected subset of the topology that intersects all of the L1 areas. Individual nodes can be L1, L2, or both (L1L2). Typical IS-IS designs require that any node or link that is to be used as transit between L2 areas must appear as part of the L2 topology. In a satellite network, any satellite could end up being used for L2 transit, and so every satellite and link would be part of L2, negating any scalability benefits from IS-IS's hierarchical structure. We elaborate on considerations specific to IS-IS in .

Assumptions In this section, we discuss some of the assumptions that are the basis for this architectural proposal. The data payload is IP packets. Satellites are active participants in the control and data planes for the network, participating in protocols and forwarding packets. There may be a terrestrial network behind each gateway that may interconnect to the broader Internet. The architecture of the terrestrial network is assumed to be a typical IS-IS and BGP deployment and is not discussed further in this document. The satellite network interconnects user stations and gateways. Interconnection between the satellite network and the satellite networks of other network operators is outside the scope of this document.

Traffic Patterns We assume that the primary use of the satellite network is to provide access from a wide range of geographic locations. We also assume that providing high-bandwidth bulk transit between peer networks is not a goal. It has been noted that satellite networks can provide lower latencies than terrestrial fiber networks in . This proposal does not preclude such applications but does not articulate the mechanisms necessary for user stations to perform the appropriate traffic engineering computations. Low-latency, multicast, and anycast applications are not discussed further in this document. As with most access networks, we assume that there will be bidirectional traffic between the user station and the gateway but that the bulk of the traffic will be from the gateway to the user station. We expect the uplink from the gateway to the satellite network to be the bandwidth bottleneck and that gateways will need to be replicated to scale the uplink bandwidth, as the satellite capacity reachable from a gateway will be limited. We assume that it is not essential to provide optimal routing for traffic from user station to user station. If this traffic is sent to a gateway first and then back into the satellite network, it might be acceptable to some operators as long as the traffic volume remains very low. This type of routing is not discussed further in this document. We assume that traffic for a user station should enter the satellite network through a gateway that is in some close geographic proximity to the user station. This is to reduce the number of ISLs used by the path to the user station. Similarly, we assume that user station traffic should exit the satellite network through the gateway that is in the closest geographic proximity to the user station. Jurisdictional requirements for landing traffic in certain regions may alter these assumptions, but such situations are outside the scope of this document. This architecture does not preclude gateway-to-gateway traffic across the satellite constellations, but it does not seek to optimize it.

User Station Constraints The user station is an entity whose operation is conceptually shared between the satellite constellation operator and the operator of the cluster of end stations it serves. For example, the user station is trusted to attach MPLS label stacks to end-user packets. It gets the information to do so from some combination of its direct satellite and its local gateway via protocols outside the scope of this document. Equally, it bootstraps communication via an exchange with the current local satellite so that it can find and communicate with its local gateway -- again with the details of how that is done being outside the scope of this document. User stations that can concurrently access multiple satellites are not precluded by this proposal but are not discussed in detail.

Stochastic Connectivity We assume that links in general will be available when scheduled. As with any network, there will be failures, and the schedule is not a guarantee, but we also expect that the schedule is mostly accurate. We assume that at any given instant, there are enough working links and aggregate bandwidth to run the network and support the traffic demand. If this assumption does not hold, no routing architecture can magically make the network more capable. Satellites that are in the same orbit may be connected by ISLs. These are called "intra-orbit" ISLs. Satellites that are in different orbits may also be connected by ISLs. These are called "inter-orbit" ISLs. Generally, we assume that intra-orbit ISLs have higher reliability and persistence than inter-orbit ISLs. We assume that the satellite network is connected (in the graph theory sense) almost always, even if some links are down. This implies that there is almost always some path to the destination. In the extreme case with no such path, we assume that it is acceptable to drop the payload packets. We do not require buffering of traffic when a link is down. Instead, traffic should be rerouted.

Problem Statement The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network. This architecture must convey topology information to relevant portions of the network. This enables path computation that is used for data forwarding. The architecture must also scale without global changes to the organizational structure.

Forwarding Plane The end goal of a network is to deliver traffic. In a satellite network where the topology is in a continual state of flux and the user stations frequently change their association with the satellites, having a highly flexible and adaptive forwarding plane is essential. Toward this end, we propose using MPLS as the fundamental forwarding plane architecture . Specifically, we propose using an approach based on Segment Routing (SR) with an MPLS data plane , where each satellite is assigned a node Segment Identifier (SID). This allows the architecture to support both IPv4 and IPv6 concurrently. A path through the network can then be expressed as a label stack of node SIDs. IP forwarding is not used within the internals of the satellite network, although each satellite may be assigned an IP address for management purposes. Existing techniques may be used to limit the size of the SR label stack so that it only contains the significant waypoints along the path . The label stack operates as a loose source route through the network. If there is an unexpected topology change in the network, the IGP will compute a new path to the next waypoint, allowing packet delivery despite ISL failures. While the IGP is converging, there may be micro-loops in the topology. These can be avoided by using Topology Independent Loop-Free Alternate (TI-LFA) paths ; otherwise, traffic will loop until discarded based on its TTL. We assume that there is a link-layer mechanism for a user station to associate with a satellite. User stations will have an IP address assigned from a prefix managed by its local gateway. The mechanisms for this assignment and its communication to the end station are not discussed herein but might be similar to DHCP . User station IP addresses change infrequently and do not reflect their association with their first-hop satellite. Gateways and their supporting terrestrial networks advertise prefixes covering all its local user stations throughout the global Internet. User stations may be assigned a node SID, in which case MPLS forwarding can be used for all hops to the user station. Alternatively, if the user station does not have a node SID, then the last hop from the satellite to the end station can be performed based on the destination IP address of the packet. This does not require a full longest-prefix-match lookup, as the IP address is merely a unique identifier at this point. Similarly, gateways may be assigned a node SID. A possible optimization is that a single SID value could be assigned as a global constant to always direct traffic to the topologically closest gateway. If traffic engineering is required for traffic that is flowing to a gateway, a specific path may be encoded in a label stack that is attached to the packet by the user station or by the first-hop satellite. Gateways can also perform traffic engineering using different paths and label stacks for separate traffic flows. Routing a single traffic flow across multiple paths has proven to cause performance issues with transport protocols, so that approach is not recommended. Traffic engineering is discussed further in .

IGP Suitability and Scalability As discussed in , IS-IS is architecturally the best fit for satellite networks but does require some novel approaches to achieve the scalability goals for a satellite network. In particular, we propose that all nodes in the network be L1L2 so that local routing is done based on L1 information and then global routing is done based on L2 information. An interesting property of IS-IS is that it does not require interface addresses. This feature is commonly known as "unnumbered interfaces". This is particularly helpful in satellite topologies because it implies that ISLs may be used flexibly. Sometimes an interface might be used as an L1 link to another satellite, and a few orbits later, it might be used as an L1L2 link to a completely different satellite without any reconfiguration or renumbering. Scalability for IS-IS can be achieved through a proposal known as "Area Proxy" . With this proposal, all nodes in an L1 area combine their information into a single L2 Link State Protocol Data Unit (LSP). This implies that the size of the L1 Link State Database (LSDB) scales as the number of nodes in the L1 area and the size of the L2 LSDB scales with the number of L1 areas. With Area Proxy, topological changes within an L1 area will not be visible to other areas, so the overhead of link-state changes will be greatly reduced. The Area Proxy proposal also includes the concept of an Area SID. This is useful because it allows traffic engineering to construct a path that traverses areas with a minimal number of label stack entries. For example, suppose that a network has 1,000 L1 areas, each with 1,000 satellites. This would mean that the network supports 1,000,000 satellites but only requires 1,000 entries in its L1 LSDB and 1,000 entries in its L2 LSDB, which are easily achievable numbers today. The resulting MPLS label table would contain 1,000 node SIDs from the L1 (and L2) LSDB and 1,000 area SIDs from the L2 LSDB. If each satellite advertises an IP address for management purposes, then the IP routing table would have 1,000 entries for the L1 management addresses and 1,000 area proxy addresses from L2. In this proposal, IS-IS does not carry IP routes other than those in the satellite topology. In particular, there are no IP routes for user stations or the remainder of the Internet.

Stripes and Areas A significant problem with any link-state routing protocol is that of area partition. While there have been many proposals for automatic partition repair, none has seen notable production deployment. It seems best to avoid this issue and ensure areas have an extremely low probability of partitioning. As discussed above, intra-orbit ISLs are assumed to have higher reliability and persistence than inter-orbit ISLs. However, even intra-orbit ISLs are not sufficiently reliable to avoid partition issues. Therefore, we propose to group a small number of adjacent orbits as an IS-IS L1 area, called a "stripe". We assume that for any given reliability requirement, there is a small number of orbits that can be used to form a stripe that satisfies the reliability requirement. Stripes are connected to other adjacent stripes using the same ISL mechanism, forming the L2 topology of the network. Each stripe should have multiple L2 connections and never become partitioned from the remainder of the network. By using a stripe as an L1 area, in conjunction with Area Proxy, the overhead of the architecture is greatly reduced. Each stripe contributes a single LSP to the L2 LSDB, completely hiding all the details about the satellites within the stripe. The resulting architecture scales proportionately to the number of stripes required, not the number of satellites. Groups of MEO and GEO satellites with interconnecting ISLs can also form an IS-IS L1L2 area. Satellites that lack intra-constellation ISLs are better as independent L2 nodes.

Traffic Forwarding and Traffic Engineering The forwarding architecture presented here is straightforward. A path from a gateway to a user station on the same stripe only requires a single node SID for the satellite that provides the downlink to the user station.

On-Stripe Forwarding \ Gateway --> X \ \ X \ \ X ---> x User Station \

Similarly, a user station returning a packet to a gateway need only provide a gateway node SID. For off-stripe forwarding, the situation is a bit more complex. A gateway would need to provide the area SID of the final stripe on the path plus the node SID of the downlink satellite. For return traffic, user stations or first-hop satellites would want to provide the area SID of the stripe that contains the satellite that provides access to the gateway as well as the gateway SID.

Off-Stripe Forwarding Source S | | V Internet | | V \ Gateway L --> X \ \ \ X --- X \ \ \ \ Area A X --- X \ \ \ U ---> D User Station \

As an example (), consider a packet from an Internet source (Source S) to a user station (D). A local gateway (Gateway L) has injected a prefix covering D into BGP and has advertised it globally. The packet is forwarded to L using IP forwarding. When L receives the packet, it performs a lookup in a pre-computed forwarding table. This contains a SID list for the user station that has already been converted into a label stack. Suppose the user station is currently associated with a different stripe so that the label stack will contain an area label (A) and a label (U) for the satellite associated with the user station, resulting in a label stack (A, U). The local gateway forwards this into the satellite network. The first-hop satellite now forwards based on the area label (A) at the top of the stack. All area labels are propagated as part of the L2 topology. This forwarding continues until the packet reaches a satellite adjacent to the destination area. That satellite pops label A, removing that label and forwarding the packet into the destination area. The packet is now forwarded based on the remaining label U, which was propagated as part of the L1 topology. The last satellite forwards the packet based on the destination address (D) and forwards the packet to the user station. The return case is similar. The label stack, in this case, consists of a label for the local gateway's stripe/area (A') and the label for the local gateway (L), resulting in the stack (A', L). The forwarding mechanisms are similar to the previous case. Very frequently, access networks congest due to over-subscription and the economics of access. Network operators can use traffic engineering to ensure that they get higher efficiency out of their networks by utilizing all available paths and capacity near any congestion points. In this particular case, the gateway will have information about all of the traffic it is generating and can use all of the possible paths through the network in its topological neighborhood. Since we're already using SR, this is easily done by adding more explicit SIDs to the label stack. These can be additional area SIDs, node SIDs, or adjacency SIDs. Path computation can be performed by Path Computation Elements (PCEs) . Each gateway or its PCE will need topological information from the areas it will route through. It can do this by participating in the IGP directly, via a tunnel, or through another delivery mechanism such as BGP-LS . User stations do not participate in the IGP. Traffic engineering for packets flowing into a gateway can also be provided by an explicit SR path. This can help ensure that ISLs near the gateway do not congest with traffic for the gateway. These paths can be computed by the gateway or PCE and then distributed to the first-hop satellite or user station, which would apply them to traffic. The delivery mechanism is outside the scope of this document.

Scheduling The most significant difference between terrestrial and satellite networks from a routing perspective is that some of the topological changes that will happen to the network can be anticipated and computed. Both link and node changes will affect the topology, and the network should react smoothly and predictably. The management plane is responsible for providing information about scheduled topological changes. The exact details of how the information is disseminated are outside the scope of this document but could be shown through a YANG model . Scheduling information needs to be accessible to all of the nodes that will make routing decisions based on the topological changes in the schedule (i.e., data about an L1 topological change will need to be circulated to all nodes in the L1 area and information about L2 changes will need to propagate to all L2 nodes) and to the gateways and PCEs that carry the related topological information. There is very little that the network should do in response to a topological addition. A link coming up or a node joining the topology should not have any functional change until the change is proven to be fully operational based on the usual IS-IS liveness mechanisms. Nodes may pre-compute their routing table changes but should not install them before all relevant adjacencies are received. The benefits of this pre-computation appear to be very small. Gateways and PCEs may also choose to pre-compute paths based on these changes but should not install paths using the new parts of the topology until they are confirmed to be operational. If some path pre-installation is performed, gateways and PCEs must be prepared for the situation where the topology fails to become operational and may need to take alternate steps instead, such as reverting any related pre-installed paths. The network may choose not to pre-install or pre-compute routes in reaction to topological additions, at a small cost of some operational efficiency. Topological deletions are an entirely different matter. If a link or node is to be removed from the topology, the network should act before the anticipated change to route traffic around the expected topological loss. Specifically, at some point before the topology change, the affected links should be set to a high metric to direct traffic to alternate paths. This is a common operational procedure in existing networks when links are taken out of service, such as when proactive maintenance needs to be performed. This type of change does require some time to propagate through the network, so the metric change should be initiated far enough in advance that the network converges before the actual topological change. Gateways and PCEs should also update paths around the topology change and install these changes before the topology change occurs. The time necessary for both IGP and path changes will vary depending on the exact network and configuration. Strictly speaking, changing to a high metric should not be necessary. It should be possible for each router to exclude the link and recompute paths. However, it seems safer to change the metric and use the IGP methods for indicating a topology change, as this can help avoid issues with incomplete information dissemination and synchronization.

Future Work This architecture needs to be validated by satellite operators, both via simulation and operational deployment. Meaningful simulation hinges on the exact statistics of ISL connectivity; currently, that information is not publicly available. Current available information about ISLs indicates that links are mechanically steered and will need to track the opposite end of the link continually. The angles and distances that can be practically supported are unknown, as are any limitations about the rate of change. It is expected that intra-orbit and inter-orbit ISL links will have very different properties. Intra-orbit links should be much more stable but still far less stable than terrestrial links. Inter-orbit links will be less stable. Links between satellites that are roughly parallel should be possible but will likely have a limited duration. Two orbits may be roughly orthogonal, resulting in a limited potential for connectivity. Finally, in some topologies there may be parallel orbits where the satellites move in opposite directions, giving a relative speed between satellites around 34,000 mph (55,000 kph). Links in this situation may not be possible or may be so short-lived that they are impractical. The key question to address is whether the parameters of a given network can yield a stripe assignment that produces stable, connected areas that work within the scaling bounds of the IGP. If links are very stable, a stripe could be just a few parallel orbits, with only a few hundred satellites. However, if links are unstable, a stripe might have to encompass dozens of orbits and thousands of satellites, which might be beyond the scaling limitations of a given IGP's implementation.

Deployment Considerations The network behind a gateway is expected to be a normal terrestrial network. Conventional routing architectural principles apply. An obvious approach would be to extend IS-IS to the terrestrial network, applying L1 areas as necessary for scalability. The terrestrial network may have one or more BGP connections to the broader Internet. Prefixes for user stations should be advertised to the Internet near the associated gateway. If gateways are not interconnected by the terrestrial network, then it may be advisable to use one autonomous system per gateway as it might simplify the external perception of the network and subsequent policy considerations. Otherwise, one autonomous system may be used for the entire terrestrial network.

Security Considerations This document discusses one possible routing architecture for satellite networks. It proposes no new protocols or mechanisms and thus has no new security impact. Security for IS-IS is provided by and . User stations will interact directly with satellites, potentially using proprietary mechanisms, and under the control of the satellite operator, who is responsible for the security of the user station.

IANA Considerations This document has no IANA actions.

References Normative References ISO/IEC This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Link-state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, thereby leading to scaling issues. To avoid such issues, this document discusses extensions to the IS-IS routing protocol that allow Level 1 (L1) areas to provide transit but only inject an abstraction of the Level 1 topology into Level 2 (L2). Each Level 1 area is represented as a single Level 2 node, thereby enabling a greater scale. Informative References American Journal of Science, vol. S3-20, no. 118, pp. 305-324 Sensors, vol. 22, no. 12, pp. 4552 CNN Business 2015 IEEE Global Communications Conference (GLOBECOM) HotNets '18: Proceedings of the 17th ACM Workshop on Hot Topics in Networks, pp. 85-91 ITU This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. Work in Progress arXiv:2310.07546v1 Futurewei Technologies LabN Consulting, L.L.C. LabN Consulting, L.L.C. LabN Consulting, L.L.C. Viagenie The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. Work in Progress 2021 IEEE 46th Conference on Local Computer Networks (LCN)

Acknowledgements The author would like to thank , , , , , , , , , and for their comments.

Author's Address Juniper Networks

tony.li@tony.li