Search RFCs

RFC Editor

File formats:

Status:

PROPOSED STANDARD

Updated by:

RFC 9256

Authors:

C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir

Stream:

IETF

Source:

spring (rtg)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC8402

Discuss this RFC: Send questions or comments to the mailing listspring@ietf.org

Other actions:View Errata  | Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 8402

Abstract

Segment Routing (SR) leverages the source routing paradigm. A nodesteers a packet through an ordered list of instructions, called"segments". A segment can represent any instruction, topological orservice based. A segment can have a semantic local to an SR node orglobal within an SR domain. SR provides a mechanism that allows aflow to be restricted to a specific topological path, whilemaintaining per-flow state only at the ingress node(s) to the SRdomain.

SR can be directly applied to the MPLS architecture with no change tothe forwarding plane. A segment is encoded as an MPLS label. Anordered list of segments is encoded as a stack of labels. Thesegment to process is on the top of the stack. Upon completion of asegment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type ofrouting header. A segment is encoded as an IPv6 address. An orderedlist of segments is encoded as an ordered list of IPv6 addresses inthe routing header. The active segment is indicated by theDestination Address (DA) of the packet. The next active segment isindicated by a pointer in the new routing header.

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.