Circuit Style Segment Routing PoliciesCisco Systems, Inc.cschmutz@cisco.comCisco Systems, Inc.cfilsfil@cisco.comCisco Systems, Inc.zali@cisco.comCisco Systems, Inc.fclad@cisco.comAirtel IndiaPraveen.Maheshwari@airtel.comCienarrokui@ciena.comNokiaandrew.stone@nokia.comVerizonluay.jalil@verizon.comHuawei Technologiespengshuping@huawei.comJuniper Networkstsaad@juniper.netBell Canadadaniel.voyer@bell.caThis document describes how Segment Routing (SR) policies can be used to satisfy the requirements for strict bandwidth guarantees, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called “circuit-style” SR policies (CS-SR policies).Segment routing does allow for a single network to carry both typical IP (connection-less) services and connection-oriented transport services commonly referred to as “private lines”. IP services typically require ECMP and TI-LFA, while transport services that normally are delivered via dedicated circuit-switched SONET/SDH or OTN networks do require:Persistent end-to-end traffic engineered paths that provide predictable and identical latency in both directionsStrict bandwidth commitment per path to ensure no impact on the Service Level Agreement (SLA) due to changing network load from other servicesEnd-to-end protection (<50msec protection switching) and restoration mechanismsMonitoring and maintenance of path integrityData plane remaining up while control plane is downSuch a “transport centric” behavior is referred to as “circuit-style” in this document.This document describes how SR policies and the use of adjacency-SIDs defined in the SR architecture together with a stateful Path Computation Element (PCE) can be used to satisfy those requirements. It includes how end-to-end recovery and path integrity monitoring can be implemented.SR policies that satisfy those requirements are called “circuit-style” SR policies (CS-SR policies).BSID : Binding Segment IdentifierCS-SR : Circuit-Style Segment RoutingID : IdentifierLSP : Label Switched PathLSPA : LSP attributesOAM : Operations, Administration and MaintenanceOF : Objective FunctionPCE : Path Computation ElementPCEP : Path Computation Element Communication ProtocolPT : Protection TypeSID : Segment IdentifierSLA : Service Level AgreementSR : Segment RoutingSTAMP : Simple Two-Way Active Measurement ProtocolTI-LFA : Topology Independent Loop Free AlternateTLV : Type Length ValueThe reference model for CS-SR policies is following the Segment Routing Architecture and SR Policy Architecture and is depicted in .By nature of CS-SR policies, paths will be computed and maintained by a stateful PCE defined in . The stateful PCE provides a consistent simple mechanism for initializing the co-routed bidirectional end to end paths, performing bandwidth allocation control, as well as monitoring facilities to ensure SLA compliance for the live of the CS-SR Policy. When using a MPLS data plane , PCEP extensions defined in will be used. When using a SRv6 data plane , PCEP extensions defined in will be used.In order to satisfy the requirements of CS-SR policies, each link in the topology MUST have:An adjacency-SID which is:
Manually allocated or persistent : to ensure that its value does not change after a node reloadNon-protected : to avoid any local TI-LFA protection to happen upon interface/link failuresThe bandwidth available for CS-SR policies specifiedA per-hop behavior ( or ) that ensures that the specified bandwidth is available to CS-SR policies at all times independent of any other trafficWhen using a MPLS data plane existing IGP extensions defined in and and BGP-LS defined in can be used to distribute the topology information including those persistent and unprotected adjacency-SIDs.When using a SRv6 data plane the IGP extensions defined in and and BGP-LS extensions in apply.In a network, resources are represented by links of certain bandwidth. In a circuit switched network such as SONET/SDH, OTN or DWDM resources (timeslots or a wavelength) are allocated for a provisioned connection at the time of reservation even if no communication is present. In a packet switched network resources are only allocated when communication is present, i.e. packets are to be sent. This allows for the total reservations to exceed the link bandwidth as well in general for link congestion.To satisfy the strict bandwidth commitment for CS-SR policies it must be ensured that packets carried by CS-SR policies can be at all times sent up to the reserved bandwidth on each hop along the path. This is done by:Firstly, ensuring traffic for each CS-SR policy is limited to the bandwidth reserved for that CS-SR policy by traffic policing or shapingSecondly, ensuring that during times of link congestion only non-CS-SR policy traffic is being buffered or dropped.For the later several approaches can be considered:Allocate a dedicated physical link of bandwidth P to CS-SR policies and allow CS-SR reservations up to bandwidth C. Consider bandwidth N allocated for network control, ensure that P - N >= CAllocate a dedicate logical link (i.e. 801.q VLAN on ethernet) to CS-SR policies on a physical link of bandwidth P. Limit the total utilization across all other logical links to bandwidth O by traffic policing or shaping and ensure that P - N - O >= CAllocate a dedicated Diffserv codepoint and queue to CS-SR policies and limit the total utilization across all other queues to bandwidth O by traffic policing or shaping and ensure that P -N - O >= CAllocate a dedicate Diffserv codepoint and strict priority queue to CS-SR policies and limit the total utilization across all priority queues of higher or equal priority to bandwidth O by traffic policing or shaping and ensure that P - N - O >= CAllocate a dedicate Diffserv codepoint and a strict priority queue with a priority higher than all other queues to CS-SR policies and limit the utilization of that priority queue by traffic policing to C <= P - NIn addition CS-SR policy telemetry collection can be used to raise alarms when bandwidth utilization thresholds are passed or to request the reserved bandwidth to be adjusted.A CS-SR policy has the following characteristics:Requested bandwidth : bandwidth to be reserved for the CS-SR policyBidirectional co-routed : a CS-SR policy between A and Z is an association of an SR-Policy from A to Z and an SR-Policy from Z to A following the same path(s)Deterministic and persistent paths : segment lists with strict hops using unprotected adjacency-SIDsNot automatically recomputed or reoptimized : the SID list of a candidate path must not change automatically to a SID list representing a different path (for example upon topology change)Multiple candidate paths in case of protection/restoration:
Following the SR policy architecture, the highest preference valid path is carrying trafficDepending on the protection/restoration scheme (), lower priority candidate paths
may be pre-computedmay be pre-programmedmay have to be disjointConnectivity verification and performance measurement is activated on each candidate path ()A CS-SR policy between A and Z is configured both on A (with Z as endpoint) and Z (with A as endpoint) as shown in .Both nodes A and Z act as PCC and delegate path computation to the PCE using the extensions defined in . The PCRpt message sent from the headends to the PCE contains the following parameters:BANDWIDTH object (Section 7.7 of ) : to indicate the requested bandwidthLSPA object (section 7.11 of ) : to indicate that no local protection requirements
L flag set to 0 : no local protectionE flag set to 1 : protection enforcement (section 5 of )ASSOCIATION object () :
Type : Double-sided Bidirectional with Reverse LSP Association ()Bidirectional Association Group TLV () :
R flag is always set to 0 (forward path)C flag is always set to 1 (co-routed)If the SR-policies are configured with more than one candidate path, a PCEP request is sent per candidate path. Each PCEP request does include the “SR Policy Association” object (type 6) as defined in to make the PCE aware of the candidate path belonging to the same policy.The signaling extensions described in are used to ensure thatPath determinism is achieved by the PCE only using segment lists representing a strict hop by hop path using unprotected adjacency-SIDs.Path persistency across node reloads in the network is achieved by the PCE only including manually configured adjacency-SIDs in its path computation response.Persistency across network changes is achieved by the PCE not performing periodic nor network event triggered re-optimization.Bandwidth adjustment can be requested after initial creation by signaling both requested and operational bandwidth in the BANDWIDTH object but the PCE is not allowed to respond with a changed path.As discussed in section 3.2 of it may be necessary to use load-balancing across multiple paths to satisfy the bandwidth requirement of a candidate path. In such a case the PCE will notify the PCC to install multiple segment lists using the signaling procedures described in section 5.3 of .A Segment Routed path defined by a segment list is constrained by maximum segment depth (MSD), which is the maximum number of segments a router can impose onto a packet. , , and provide the necessary capabilities for a PCE to determine the MSD capability of a router. The MSD constraint is typically resolved by leveraging a label stack reduction technique, such as using Node SIDs and/or BSIDs (SR architecture ) in a segment list, which represents one or many hops in a given path.As described in , adjacency-SIDs without local protection are to be used for CS-SR policies to ensure no ECMP, no rerouting due to topological changes nor localized protection is being invoked on the traffic, as the alternate path may not be providing the desired SLA.If a CS-SR Policy path requires SID List reduction, a Node SID cannot be utilized as it is eligible for traffic rerouting following IGP re-convergence. However, a BSID can be programmed to a transit node, if the following requirements are met:The BSID is unprotected, hence only has one candidate pathThe BSID follows the rerouting and optimization characteristics defined in which implies the SID list of the candidate path MUST only use unprotected adjacency-SIDs.This ensures that any CS-SR policies in which the BSID provides transit for do not get rerouted due to topological changes or protected due to failures. A BSID may be pre-programmed in the network or automatically injected in the network by a PCE.Various protection and restoration schemes can be implemented. The terms “protection” and “restoration” are used with the same subtle distinctions outlined in section 1 of , and respectively.Protection : another candidate path is computed and fully established in the data plane and ready to carry trafficRestoration : a candidate path may be computed and may be partially established but is not ready to carry trafficThe term “failure” is used to represent both “hard failures” such complete loss of connectivity detected by or degradation, a packet loss ratio, beyond a configured acceptable threshold.In the most basic scenario no protection nor restoration is required. The CS-SR policy has only one candidate path configured. This candidate path is established, activated (O field in LSP object is set to 2) and is carrying traffic.In case of a failure the CS-SR policy will go down and traffic will not be recovered.Typically two CS-SR policies are deployed either within the same network with disjoint paths or in two completely separate networks and the overlay service is responsible for traffic recovery.For fast recovery against failures the CS-SR policy is configured with two candidate paths. Both paths are established but only the candidate with higher preference is activated (O field in LSP object is set to 2) and is carrying traffic. The candidate path with lower preference has its O field in LSP object set to 1.Appropriate routing of the protect path diverse from the working path can be requested from the PCE by using the “Disjointness Association” object (type 2) defined in in the PCRpt messages. The disjoint requirements are communicated in the “DISJOINTNESS-CONFIGURATION TLV”L bit set to 1 for link diversityN bit set to 1 for node diversityS bit set to 1 for SRLG diversityT bit set to enforce strict diversityThe P bit may be set for first candidate path to allow for finding the best working path that does satisfy all constraints without considering diversity to the protect path.The “Objective Function (OF) TLV” as defined in section 5.3 of may also be added to minimize the common shared resources.Upon a failure impacting the candidate path with higher preference carrying traffic, the candidate path with lower preference is activated immediately and traffic is now sent across it.Protection switching is bidirectional. As described in , both headends will generate and receive their own loopback mode test packets, hence even a unidirectional failure will always be detected by both headends without protection switch coordination required.Two cases are to be considered when the failure impacting the candidate path with higher preference is cleared:Revertive switching : re-activate the candidate path, change O field from 0 to 2 and start sending traffic over itNon-revertive switching : do not activate the candidate path, change O field from 0 to 1, keep the second candidate path active with O field set to 2 and continue sending traffic over itCompared to 1:1 protection described in , this restoration scheme avoids pre-allocating protection bandwidth in steady state, while still being able to recover traffic flow in case of a network failure in a deterministic way (maintain required bandwidth commitment)The CS-SR policy is configured with two candidate paths. The candidate path with higher preference is established, activated (O field in LSP object is set to 2) and is carrying traffic.The second candidate path with lower preference is only established and activated (O field in LSP object is set to 2) upon a failure impacting the first candidate path in order to send traffic over an alternate path through the network around the failure with potentially relaxed constraints but still satisfying the bandwidth commitment.The second candidate path is generally only requested from the PCE and activated after a failure, but may also be requested and pre-established during CS-SR policy creation with the downside of bandwidth being set aside ahead of time.As soon as failure(s) that brought the first candidate path down are cleared, the second candidate path is getting deactivated (O field in LSP object is set to 1) or torn down. The first candidate path is activated (O field in LSP object is set to 2) and traffic sent across it.Restoration and reversion behavior is bidirectional. As described in , both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.For further resiliency in case of multiple concurrent failures that could affect both candidate paths of 1:1 protection described in , a third candidate path with a preference lower than the other two candidate paths is added to the CS-SR policy.The third candidate path enables restoration and will generally only be established, activated (O field in LSP object is set to 2) and carry traffic after failure(s) have impacted both the candidate path with highest and second highest preference.The third candidate path may also be requested and pre-computed already whenever either the first or second candidate path went down due to a failure with the downside of bandwidth being set aside ahead of time.As soon as failure(s) that brought either the first or second candidate path down are cleared the third candidate path is getting deactivated (O field in LSP object is set to 1), the candidate path that recovered is activated (O field in LSP object is set to 2) and traffic sent across it.Again restoration and reversion behavior is bidirectional. As described in , both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.The proper operation of each segment list is validated by both headends using STAMP in loopback measurement mode as described in section 4.2.3 of .As the STAMP test packets are including both the segment list of the forward and reverse path, standard segment routing data plane operations will make those packets get switched along the forward path to the tailend and along the reverse path back to the headend.The headend forms the bidirectional SR Policy association using the procedure described in and receives the information about the reverse segment list from the PCE as described in section 4.5 of The same STAMP session is used to estimate round-trip loss as described in section 5 of .The same STAMP session used for connectivity verification can be used to measure delay. As loopback mode is used only round-trip delay is measured and one-way has to be derived by dividing the round-trip delay by two.A stateful PCE is in sync with the network topology and the CS-SR Policies provisioned on the headend routers. As described in a path must not be automatically recomputed after or optimized for topology changes. However there may be a requirement for a PCE to tear down a path if the path no longer satisfies the original requirements, detected by PCE, such as insufficient bandwidth, diversity constraint no longer met or latency constraint exceeded.The PCC may measure the actual bandwidth utilization of a CS-SR policy to take local action and/or report it to the PCE. Typical actions are raising alarms or adjusting the reserved bandwidth.For a CS-SR policy configured with multiple candidate paths, a PCC may switch to another candidate path if the PCE decided to tear down the active candidate path.It is very common to allow operators to trigger a switch between candidate paths even if no failure is present. I.e. to proactively drain a resource for maintenance purposes. Operator triggered switching between candidate paths is unidirectional and has to be requested on both headends.While no automatic re-optimization or pre-computation of CS-SR policy candidate paths is allowed as specified in , network operators trying to optimize network utilization may explicitly request a candidate path to be re-computed at a certain point in time.TO BE ADDEDThis document has no IANA actions.The author’s want to thank Samuel Sidor, Mike Koldychev, Rakesh Gandhi and Tarek Saad for providing their review comments.Contributors' AddressesKey words for use in RFCs to Indicate Requirement LevelsIn 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.Segment Routing Policy ArchitectureCisco SystemsCisco SystemsBell CanadaBritish TelecomMicrosoftSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
Segment Routing ArchitectureSegment 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.Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.Segment Routing with the MPLS Data PlaneSegment 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).Path Computation Element Communication Protocol (PCEP) Extensions for Segment RoutingSegment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.This document updates RFC 8408.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplaneHuawei TechnologiesRtBrick IncCiena CorporationCisco Systems, Inc.RtBrick IncChina Telecom The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm.
SR enables any head-end node to select any path without relying on a
hop-by-hop signaling technique (e.g., LDP or RSVP-TE).
It depends only on "segments" that are advertised by Link-State IGPs.
A Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or
a PCE.
Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
should be able to compute SR-Path for both MPLS and IPv6 forwarding
plane. This document describes the extensions required for SR
support for IPv6 data plane in Path Computation Element communication
Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS
is described in RFC 8664. This document extends it to support SRv6
(SR over IPv6).
An Expedited Forwarding PHB (Per-Hop Behavior)This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]Assured Forwarding PHB GroupThis document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]IS-IS Extensions for Segment RoutingSegment 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 RoutingSegment 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.Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment RoutingSegment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.IS-IS Extensions to Support Segment Routing over IPv6 DataplaneCisco SystemsCisco SystemsCisco SystemsOrangeHuawei Technologies The Segment Routing (SR) architecture allows flexible definition of
the end-to-end path by encoding it as a sequence of topological
elements called "segments". It can be implemented over the MPLS or
the IPv6 data plane. This document describes the IS-IS extensions
required to support Segment Routing over the IPv6 data plane.
This document updates RFC 7370 by modifying an existing registry.
OSPFv3 Extensions for SRv6Huawei TechnologiesHuawei TechnologiesCisco SystemsCisco Systems The Segment Routing (SR) architecture allows a flexible definition of
the end-to-end path by encoding it as a sequence of topological
elements called segments. It can be implemented over an MPLS or IPv6
data plane. This document describes the OSPFv3 extensions required
to support Segment Routing over the IPv6 data plane (SRv6).
BGP Link State Extensions for SRv6LinkedInCisco SystemsCisco SystemsHuaweiBell CanadaOrange Segment Routing over IPv6 (SRv6) allows for a flexible definition of
end-to-end paths within various topologies by encoding paths as
sequences of topological or functional sub-paths, called "segments".
These segments are advertised by various protocols such as BGP, IS-IS
and OSPFv3.
This document defines extensions to BGP Link-state (BGP-LS) to
advertise SRv6 segments along with their behaviors and other
attributes via BGP. The BGP-LS address-family solution for SRv6
described in this document is similar to BGP-LS for SR for the MPLS
data-plane defined in a separate document.
Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]Local Protection Enforcement in PCEPNokiaNokiaCisco Systems, Inc.Ciena Coroporation This document extends the base specification to clarify usage of the
local protection desired bit signalled in the Path Computation
Element Protocol (PCEP). This document also introduces a new flag
for signalling protection strictness in PCEP.
Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) PathsHuawei TechnologiesHuawei TechnologiesChina MobileCisco Systems, Inc.ZTE Corporation The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
Segment routing (SR) leverages the source routing and tunneling
paradigms. The Stateful PCEP extensions allow stateful control of
Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP
can be used for computing SR TE paths in the network.
This document defines PCEP extensions for grouping two unidirectional
SR Paths (one in each direction in the network) into a single
associated bidirectional SR Path. The mechanisms defined in this
document can also be applied using a stateful PCE for both PCE-
initiated and PCC-initiated LSPs or when using a stateless PCE.
Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.PCEP extension to support Segment Routing Policy Candidate PathsCisco SystemsCiena CorporationJuniper NetworksHuawei TechnologiesNokia This document introduces a mechanism to specify a Segment Routing
(SR) policy, as a collection of SR candidate paths. An SR policy is
identified by <headend, color, endpoint> tuple. An SR policy can
contain one or more candidate paths where each candidate path is
identified in PCEP by its uniquely assigned PLSP-ID. This document
proposes extension to PCEP to support association among candidate
paths of a given SR policy. The mechanism proposed in this document
is applicable to both MPLS and IPv6 data planes of SR.
PCEP extensions for Circuit Style PoliciesCisco Systems, Inc.Cisco Systems, Inc.Airtel IndiaCienaNokiaVerizonHuawei TechnologiesJuniper NetworksBell Canada This document proposes a set of extensions for Path Computation
Element Communication Protocol (PCEP) for Circuit Style Policies -
Segment-Routing Policy designed to satisfy requirements for
connection-oriented transport services. New TLV is introduced to
control path recomputation and new flag to add ability to request
path with strict hops only.
PCEP Extensions for Signaling Multipath InformationCisco Systems, Inc.Ciena CorporationJuniper Networks, Inc.Juniper Networks, Inc.NokiaCienaHuawei TechnologiesVerizon Inc. Path computation algorithms are not limited to return a single
optimal path. Multiple paths may exist that satisfy the given
objectives and constraints. This document defines a mechanism to
encode multiple paths for a single set of objectives and constraints.
This is a generic PCEP mechanism, not specific to any path setup type
or dataplane. The mechanism is applicable to both stateless and
stateful PCEP.
Signaling Maximum SID Depth (MSD) Using IS-ISThis document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.Signaling Maximum SID Depth (MSD) Using OSPFThis document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link StateThis document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) RecoveryThis document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.Network Hierarchy and Multilayer SurvivabilityPath Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint SignalingThis document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing NetworksCisco Systems, Inc.Cisco Systems, Inc.Bell CanadaHuaweiColtNokia Segment Routing (SR) leverages the source routing paradigm. SR is
applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) data planes. This document describes procedures for
Performance Measurement in SR networks using the mechanisms defined
in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and
its optional extensions defined in RFC 8972 and further augmented in
draft-ietf-ippm-stamp-srpm. The procedure described is applicable to
SR-MPLS and SRv6 data planes and is used for both links and end-to-
end SR paths including SR Policies.
The Twelve Networking TruthsThis memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.