Segment-Routing over Forwarding Adjacency Links
Juniper Networks, Inc.
tsaad@juniper.net
Juniper Networks, Inc.
vbeeram@juniper.net
Juniper Networks, Inc.
cbarth@juniper.net
Ciena Corporation.
ssivabal@ciena.com
SPRING Working Group
Internet-Draft
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS)
networks can be used to form Forwarding Adjacency (FA) links that carry traffic
in those networks. An FA link can be assigned Traffic Engineering (TE)
parameters that allow other LSR(s) to include it in their constrained path
computation. FA link(s) can be also assigned Segment-Routing (SR) segments
that enable the steering of traffic on to the associated FA link(s). The TE and SR
attributes of an FA link can be advertised using known protocols that carry link state
information. This document elaborates on the usage of FA link(s) and their attributes
in SR enabled networks.
To improve scalability in Multi-Protocol Label Switching (MPLS) networks, it
may be useful to create a hierarchy of LSPs as Forwarding Adjacencies (FA).
The concept of FA link(s) and FA-LSP(s) was introduced in .
In Segment-Routing (SR), this is particularly useful for two main reasons.
First, it allows the stitching of sub-path(s) so as to realize an end-to-end SR
path. Each sub-path can be represented by a FA link that is supported by one
or more underlying LSP(s). The underlying LSP(s) that support an FA link can be
setup using different technologies– including RSVP-TE, LDP, and SR. The
sub-path(s), or FA link(s) in this case, can possibly interconnect multiple
administrative domains, allowing each FA link within a domain to use a
different technology to setup the underlying LSP(s).
Second, it allows shortening of a large SR Segment-List by compressing one or
more slice(s) of the list into a corresponding FA TE link that each can be
represented by a single segment- see . Effectively, it reduces
the number of segments that an ingress router has to impose to realize an
end-to-end path.
The FA links are treated as normal link(s) in the network and hence it can
leverage existing link state protocol extensions to advertise properties
associated with the FA link. For example, Traffic-Engineering (TE) link
parameters and Segment-Routing (SR) segments parameters can be associated
with the FA link and advertised throughout the network.
Once advertised in the network using a suitable protocols that support carrying
link state information, such as OSPF, ISIS or BGP Link State (LS)), other LSR(s) in the
network can use the FA TE link(s) as well as possibly other normal TE link(s)
when performing path computation and/or when specifying the desired explicit
path.
Though the concepts discussed in this document are specific to MPLS technology,
these are also extensible to other dataplane technologies - e.g. SRv6.
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.
FA Link(s) can be created and supported by underlying FA LSPs. The FA link is
of type point-to-point. FA links may be represented as either unnumbered or numbered.
The nodes connected by an FA link do not usually establish a routing
adjacency over the FA link. When FA links are numbered with IPv4 addresses, the
local and remote IPv4 addresses can come out of a /31 that is allocated by the LSR
that originates the FA-LSP. For unnumbered FA link(s), other provisions may
exist to exchange link identifier(s) between the endpoints of the FA.
In general, the creation/termination of an FA link and its FA-LSP is driven
either via configuration on the LSR at the head-end of the adjacency, or
dynamically using suitable North Bound Interface (NBI) protocol, e.g. Netconf,
gRPC, PCEP, etc.
The following FA-LSP attributes may be configured, including: bandwidth and
resource colors, and other constraints. The path taken by the FA-LSP may be either
computed by the LSR at the head-end of the FA-LSP, or externally by a PCE and
furnished to the headend.
The attributes of the FA link can be inherited from the underlying LSP(s) that
induced its creation. In general, for dynamically provisioned FAs, a
policy-based mechanism may be needed to associate link attributes to those of
the FA-LSPs.
When the FA link is supported by bidirectional FA LSP(s), a pair of FA link(s) are
advertised from each endpoint of the FA. These are usually referred to as symmetrical
link(s).
Multiple protocols exist that can exchange link state information in the
network. For example, when advertising TE link(s) and their attribute(s) using
OSPF and ISIS protocols, the respective extensions are defined in
and . Also, when exchanging such information in BGP protocol,
extensions for BGP link state are defined in and . The
same protocol encodings can be used to advertise FA(s) as TE link(s). As a
result, the FA TE link(s) and other normal TE link(s) will appear in the TE
link state database of any LSR in the network, and can be used for computing
end-to-end TE path(s).
When IGP protocols are used to advertise link state information about FA links,
the FA link(s) can appear in both the TE topology, as well as the IGP topology.
The use of FA link in the IGP topology may result in undesirable routing loops.
A router SHOULD leverage exisitng mechanisms to exclude the FA link from the
IGP Shortest Path First (SPF) computations, and to restrict its use
within the TE topology for traffic engineered paths computation.
For example, when using ISIS to carry FA link state information,
section 3 describes a way to restrict the link to the TE topology by setting
the IGP link metric to maximum (2^24 - 1). Alternatively, when using OSPF, the
FA link(s) can be advertised using TE Opaque LSA(s) only, and hence, strictly
show up in the TE topology as described in .
The LSR that hosts an FA link can setup the underlying LSP(s) using different
technologies - e.g. RSVP-TE, LDP, and SR.
The FA link can be supported by one or more underlay LSP(s) that terminate on
the same remote endpoint. The underlay path(s) can be setup using different
signaling technologies, e.g. using RSVP-TE, LDP, SR, etc. When multiple LSP(s)
support the same FA link, the attributes of the FA link can be derived from the
aggregate properties of each of the underlying LSP(s).
The state of an FA TE link reflects the state of the underlying LSP path that supports
it. The TE link is assumed operational and is advertised as long as the underlying
LSP path is valid. When all underlying LSP paths are invalidated, the FA TE link
advertisement is withdrawn.
The TE metrics and TE attributes are used by path computation algorithms to
select the TE link(s) that a TE path traverses. When advertising an FA link
in OSPF or ISIS, or BGP-LS, the following TE parameters are defined:
the FA link advertisement can include information about TE, IGP, and other
performance metrics (e.g. delay, and loss). The FA link TE metrics, in this case,
can be derived from the underlying path(s) that support the FA link by
producing the path accumulative metrics. When multiple LSP(s) support the same FA
link, then the higher accumulative metric amongst the LSP(s) is inherited by
the FA link.
An FA link can be assigned (e.g. via configuration) a specific set of
admin-groups. Alternatively, in some cases, this can be derived from the
underlying path affinity - for example, the underlying path strictly includes a
specific admin-group.
An FA advertisement could contain the information about the Shared Risk Link
Groups (SRLG) for the path taken by the FA LSP associated with that FA. This
information may be used for path calculation by other LSRs. The information
carried is the union of the SRLGs of the underlying TE links that make up the
FA LSP path. It is possible that the underlying path information might change
over time, via configuration updates or dynamic route modifications, resulting
in the change of the union of SRLGs for the FA link. If multiple LSP(s)
support the same FA link, then it is expected all LSP(s) have the same SRLG
union - note, that the exact paths need not be the same.
It is worth noting, that topology changes in the network may affect the FA link
underlying LSP path(s), and hence, can dynamically change the TE metrics and TE
attributes of the FA links.
It is possible for the FA link to be numbered or unnumbered.
describes a procedure for identifying a numbered FA TE link using IPv4
addresses.
For unnumbered FA link(s), the assignment and handling of the local and remote
link identifiers is specified in . The LSR at each end of the
unnumbered FA link assigns an identifier to that link. This identifier is a
non-zero 32-bit number that is unique within the scope of the LSR that assigns
it. There is no a priori relationship between the identifiers assigned to a
link by the LSRs at each end of that link.
The FA link is a unidirectional and point-to-point link. Hence, the combination
of link local identifier and advertising node can uniquely identify the link in
the TED. In some cases, however, it is desirable to associate the forward and
reverse FA links in the TED. In this case, the combination of link local and
remote identifier can identify the pair of forward and reverse FA link(s). The
LSRs at the two end points of an unnumbered link can exchange with each other
the identifiers they assign to the link. Exchanging the identifiers may be
accomplished by configuration, or by means of protocol extensions. For example,
when the FA link is established over RSVP-TE FA LSP(s), then RSVP extensions
have been introduced to exchange the FA link identifier in . Other
protocol extensions pertaining to specific link state protocols, and LSP setup
technologies will be discussed in a separate document.
If the link remote identifier is unknown, the value advertised
is set to 0 .
The Segment Routing (SR) architecture describes that an IGP
adjacency can be formed over a FA link – in which the remote node of an IGP
adjacency is a non-adjacent IGP neighbor.
In Segment-Routing (SR), the adjacency that is established over a link can be
assigned an SR Segment . For example, the Adj-SID allows to
strictly steer traffic on to the specific adjacency that is associated with the
Adj-SID.
Extensions have been defined to ISIS and OSPF in
order to advertise the the Adjacency-SID associated with a specific IGP
adjacency. The same extensions apply to adjacencies over FA link. A node can
bind an Adj-SID to an FA data-link. The Adj-SID dictates the forwarding of
packets through the specific FA link or FA link(s) identified by the Adj-SID,
regardless of its IGP/SPF cost.
When the FA link Adj-SID is supported by a single underlying LSP that is
associated with a binding label or SID, the same binding label can be used for
the FA link Adj-SID. For example, if the FA link is supported by an SR Policy
that is assigned a Binding SID B, the Adj-SID of the FA link can be assigned
the same Binding SID B.
When the FA link Adj-SID is supported by multiple underlying LSP(s) or SR
Policies - each having its own Binding label or SID, an independent FA link
Adj-SID is allocated and bound to the multiple underlying LSP(s).
Adj-SIDs can also be used in order to represent a set of parallel FA link(s)
between two endpoints.
When parallel FA links are associated with the same Adj-SID, a “weight” factor
can be assigned to each link and advertised with the Adj-SID advertised with
each FA link. The weight informs the ingress (or an SDN/orchestration system)
about the load-balancing factor over the parallel adjacencies.
BGP segments are allocated and distributed by BGP. The SR architecture
defines three types of BGP segments for Egress Peer Engineering (EPE): PeerNode
SID, PeerAdj SID, and PeerSet SID.
The applicability of each of the three types to FA links is
discussed below:
o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At the BGP
node advertising, the forwarding semantics are:
SR operation: NEXT.
Next-Hop: forward over any FA link associated with the segment that
terminates on remote endpoint.
o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the BGP node
advertising it, the forwarding semantics are:
SR operation: NEXT.
Next-Hop: forward over the specific FA link to the remote endpoint to
which the segment is related.
o PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the BGP node
advertising it, the semantics are:
SR operation: NEXT.
Next-Hop: load-balance across any of the FA links to any remote endpoint
in the related set. The group definition is a policy set by the
operator.
In order to determine the potential to establish a TE path through a series of
interconnected domains or multi-domain network, it is necessary to have
available a certain amount of TE information about each network domain. This
need not be the full set of TE information available within each network but
does need to express the potential of providing such TE connectivity.
Topology abstraction is described in . Abstraction allows applying
a policy to the available TE information within a domain so to produce
selective information that represents the potential ability to connect across
the domain. Thus, abstraction does not necessarily offer all possible
connectivity options, but presents a general view of potential connectivity
according to the policies that determine how the domain’s administrator wants
to allow the domain resources to be used.
Hence, the domain may be constructed as a mesh of border node to border node TE
FA links. When computing a path for an LSP that crosses the domain, a
computation point can see which domain entry points can be connected to which
others, and with what TE attributes.
This document has no IANA actions.
The authors would like to thank Peter Psenak for reviewing and providing valuable feedback
on this document.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Traffic Engineering (TE) Extensions to OSPF Version 2
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
IS-IS Extensions for Traffic Engineering
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and 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 new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual 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).
BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.
Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]
IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]
Segment Routing Architecture
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.
IS-IS Extensions for Segment Routing
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.
OSPF Extensions for Segment Routing
Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the OSPFv2 extensions required for Segment Routing.
Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.