Basics
1. MPLS Label Forwarding with No Swapping
Publication: IETF Individual Draft
Publication History: 2015-07
Publication URL: https://tools.ietf.org/html/draft-fang-mpls-label-forwarding-no-swap-00
Description:
This document defines MPLS label forwarding operation with no label swapping as a new MPLS label operation extension to the existing basic forwarding operation of label push, pop, and swap.
SFL
1. MultiProtocol Label Switching (MPLS) Source Label
Publication: IETF Individual Draft
Publication History: 2013-07
Publication URL: https://tools.ietf.org/html/draft-chen-mpls-source-label-00
Description:
An MultiProtocol Label Switching (MPLS) label is originally defined to identify a Forwarding Equivalence Class (FEC), a packet is assigned to a specific FEC based on its network layer destination address. It’s difficult or even impossible to derive the source information from the label. For some applications, source identification is a critical requirement. For example, performance monitoring, traffic matrix measurement and collection, where the monitoring node needs to identify where a packet was sent from.
This document introduces the concept of Source Label (SL) that is carried in the label stack and used to identify the ingress Label Switching Router (LSR) of an Label Switched Path (LSP).
2. MPLS Flow Identification Considerations
Publication: IETF RFC
Publication History: 2018-05
Publication URL: https://tools.ietf.org/html/rfc8372
Description:
This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.
3. Synonymous Flow Label Framework
Publication: IETF WG Draft
Publication History: 2018-12
Publication URL: https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04
Description:
RFC 8372 describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called Synonymous Flow Labels in which labels which mimic the behaviour of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the on the packet at the receiving label switching router.
4. RFC6374 Synonymous Flow Labels
Publication: IETF WG Draft
Publication History: 2017-06
Publication URL: https://tools.ietf.org/html/draft-ietf-mpls-rfc6374-sfl-00
Description:
This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374.
Aggregation Label
1. MVPN/EVPN Tunnel Aggregation with Common Labels
Publication: IETF WG Draft
Publication History: 2018-11
Publication URL: https://tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-00
Description:
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD. (In some cases, a distinct upstream-assigned is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures.
Tunnel Segment
1. Tunnel Segment in Segment Routing
Publication: IETF Individual Draft
Publication History: 2015-09
Publication URL: https://tools.ietf.org/html/draft-li-spring-tunnel-segment-00
Description:
This document introduces a new type of segment, Tunnel Segment, for the segment routing (SR). Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. Forwarding mechanisms and requirements of control plane and data models for tunnel segments are also defined.
2. PCEP Extensions for Tunnel Segment
Publication: IETF Individual Draft
Publication History: 2015-09
Publication URL: https://tools.ietf.org/html/draft-li-pce-tunnel-segment-00
Description:
[I-D.li-spring-tunnel-segment] introduces a new type of segment, Tunnel Segment, for the segment routing. Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. A binding label can be assigned to tunnel segment. An upstream node can use such a binding label for steering traffic into the appropriate tunnel. This document specifies a set of extensions to PCEP to support that PCC reports binding label of tunnel to PCE and that PCE allocates label for tunnel and updates label binding of tunnel to PCC.
MT Segment
1. Multi-Topology (MT) Segment in Segment Routing
Publication: IETF Individual Draft
Publication History: 2016-03
Publication URL: https://tools.ietf.org/html/draft-li-spring-multi-topology-segment-00
Description:
Multi-Topologies (MTs) can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. This document proposes the multi-topology segment for segment routing. MRT FRR using multi-topology segment is described as the use case to explains the procedures of the forwarding plane and the control plane for multi-topology segment.
2. IS-IS Extensions for MPLS Multi-Topology
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-isis-mpls-multi-topology-00
Description:
MPLS plays a key role in the process of implementing network virtualization. [I-D.li-mpls-network-virtualization-framework] proposes the framework to implement MPLS virtual network basedn on the architecture of central controller IGP. This document defines the corresponding IS-IS protocol extension and procedures to support MPLS Multi-Topology.
Bandwidth-Guaranteed SR
1. IS-IS Extensions for MPLS Virtual Nodes and Virtual Links
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-isis-mpls-vnode-vlink-00
Description:
MPLS plays a key role in the process of implementing network virtualization. [I-D.li-mpls-network-virtualization-framework] proposes the framework to implement MPLS virtual network based on the architecture of central controller IGP. This document defines the corresponding IS-IS protocol extension and procedures to implement virtual nodes node and virtual link based on MPLS global label.
MPLS Path Programming
1. BGP Extensions for Service-Oriented MPLS Path Programming (MPP)
Publication: IETF Individual Draft
Publication History: 2014-07
Publication URL: https://tools.ietf.org/html/draft-li-idr-mpls-path-programming-00
Description:
Service-oriented MPLS programming is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to allocate MPLS segment, download programmed MPLS path and the mapping of the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming.
Segment Path Programming
1. IS-IS Extensions for Segment Path Programming
Publication: IETF Individual Draft
Publication History: 2016-03
Publication URL: https://tools.ietf.org/html/draft-li-isis-spp-extensions-00
Description:
Segment Routing (SR) facilitates the steering of unicast traffic through leveraging the source routing paradigm. As introduced in Segment Path Programming (SPP), the concept of segment could be used in a more generalized manner that may be beyond reachability. This document describes the necessary IS-IS extensions for those cases.
SFC
1. Service Function Chaining Use Case
Publication: IETF Individual Draft
Publication History: 2014-04
Publication URL: https://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00
Description:
This document describes a particular use case for SPRING where the Segment Routing mechanism is leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path).
Big Label
1. MPLS Deployments and Use Cases That Cannot be Solved By Using 20-bit Label
Publication: IETF Individual Draft
Publication History: 2014-06
Publication URL: https://tools.ietf.org/html/draft-lzl-mpls-ucase-n-20bit-label-limitation-00
Description:
The MPLS label format and encoding method are specified in [RFC3032], the label value is represented using the 20-bit space and supports up to 1 million of instances. As exponential Internet growth continues there are specific network deployment scenarios where a clear need to represent more than one million entities is required. This document describes the MPLS deployment scenarios, use cases, and requirements, where the current 20-bit label will no longer be sufficient.
2. Mega Label - Expansion of MPLS Label Range
Publication: IETF Individual Draft
Publication History: 2013-07
Publication URL: https://tools.ietf.org/html/draft-li-mpls-mega-label-00
Description:
This document describes the requirement scenarios for expansion of MPLS label range. This document also introduce a framework for expansion of MPLS label range-“Mega Label” and the corresponding protocol extensions. This document will update RFC 3032, 5036, 3209 and 3107 if approved.
Label Stack Distribution
1. LDP and RSVP-TE Extensions for Label Stack Distribution
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-mpls-label-stack-distribution-00
Description:
This document defines the necessary extension for LDP and RSVP-TE to distribute more than one label (label stack) for specific FEC between label distribution peers.