Usecases for MPLS Indicators and Ancillary DataJuniper Networkstsaad@juniper.netFuturewei Technologieskiranm@futurewei.comFuturewei Technologieshaoyu.song@futurewei.comMPLS Working GroupInternet-DraftThis document presents a number of use cases that have a common need for encoding
MPLS function indicators and ancillary data inside MPLS packets. The use cases described
are not an exhaustive set, but rather the ones that are actively discussed at the
MPLS Working Group.This document describes important cases that require carrying
additional ancillary data within the MPLS packets, as well as the means to indicate
ancillary data is present.These use cases have been identified by the MPLS working group design team
working on defining MPLS function indicators and ancillary data for the MPLS data
plane. The use cases described in this document will be used to assist in
identifying requirements and issues to be considered for future resolution by
the working group.ID: draft-gandhi-mpls-ioam describes applicability of IOAM to MPLS dataplane.RFC 8986 describes the network programming usecase for SRv6 dataplane.RFC 8595 describes solution for MPLS-based forwarding for Service Function ChainingThe following terminology is used in the document:
a well-defined composite of a set of
endpoints, the connectivity requirements between subsets of these
endpoints, and associated requirements; the term ‘network slice’
in this document refers to ‘IETF network slice’ as defined in
.
controller that is used to realize an IETF network slice .
the collection of resources that are used to support a slice aggregate.
Networks that transport time sensitive traffic.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.MIAD: MPLS Label Stack Indicators for Ancillary DataISD: In-stack dataPSD: Post-stack dataMPLS: Multiprotocol Label SwitchingIn-situ Operations, Administration, and Maintenance (IOAM) records operational
and telemetry information within the packet while the packet traverses a
particular path in a network domain.The term “in-situ” refers to the fact that the IOAM data fields are added to
the data packets rather than being sent within the probe packets specifically
dedicated to OAM or Performance Measurement (PM).IOAM can run in two modes End-to-End (E2E) and Hop-by-Hop (HbH). In E2E mode,
only the encapsulating and decapsulating nodes will process IOAM data fields.
In HbH mode, the encapsulating and decapsulating nodes as well as intermediate
nodes process IOAM data fields.The IOAM data fields are defined in , and can be
used for various use-cases of OAM and PM. defines how IOAM data fields are transported using
the MPLS data plane encapsulations, including Segment Routing (SR) with MPLS
data plane (SR-MPLS).IOAM data are added after the bottom of the
label stack. The IOAM data fields can be of fixed or incremental size as defined
in . describes applicability
of IOAM to MPLS dataplane. The encapsulating MPLS node needs to know if the
decapsulating MPLS node can process the IOAM data before adding it in the
packet. specifies the definition of a network
slice for use within the IETF and discusses the general framework for
requesting and operating IETF Network Slices, their characteristics, and the
necessary system components and interfaces.Multiple network slices can be realized on top of a single shared network.In order to overcome scale challenges, IETF Network Slices may be aggregated
into groups according to similar characteristics. The slice aggregate
is a construct that comprises of the traffic
flows of one or more IETF Network Slices of similar characteristics.A router that requires forwarding of a packet that belongs to a slice aggregate
may have to decide on the forwarding action to take based on selected
next-hop(s), and the forwarding treatment (e.g., scheduling and drop policy) to
enforce based on the associated per-hop behavior.The routers in the network that forward traffic over links that are shared by
multiple slice aggregates need to identify the slice aggregate packets
in order to enforce the associated forwarding action and treatment.An IETF network slice need MAY support the following key features:A Slice SelectorA Network Resource Partition associated with a slice aggregate.A Path selection criteriaVerification that per slice SLOs are being met. This may be done by active measurements
(inferred) or by using IOAM.Additionally, there is an on-going discussion on using Service Functions
(SFs) with network slices. This may require insertion of an NSH.For multi-domain scenarios, a packet that traverses multiple domains may
encode different identifiers within each domain.A Global Identifier as a Slice Selector (GISS) can be encoded in the MPLS
packet as defined in ,
, and
. The Global Identifier
Slice Selector can be used to associate the packets to the slice aggregate,
independent of the MPLS forwarding label that is bound to the destination.
LSRs use the MPLS forwarding label to determine the forwarding next-hop(s), and
use the Global Identifier Slice Selector field in the packet to infer the
specific forwarding treatment that needs to be applied on the packet.The GISS can be encoded within an MPLS label that is carried in the packet’s
MPLS label stack. All packets that belong to the same slice aggregate MAY
carry the same GISS in the MPLS label stack. It is also possible to have
multiple GISS’s map to the same slice aggregate. The GISS can be encoded in an
MPLS label and may appear in several positions in the MPLS label stack. states in Section 2.1 that: ‘Some routers analyze a packet’s
network layer header not merely to choose the packet’s next hop, but also to
determine a packet’s “precedence” or “class of service”’.It is possible by assigning a unique MPLS forwarding label to each slice
aggregate (FEC) to distinguish the packets forwarded to the same destination
but that belong to different slice aggregates. In this case, LSRs can use the
top forwarding label to infer both the forwarding action and the forwarding
treatment to be invoked on the packets. A similar approach is described in
and .The routers in a network can perform two distinct functions on incoming packets, namely forwarding
(where the packet should be sent) and scheduling (when the packet should be
sent). Time Sensitive Networking (TSN) and Deterministic Networking provide several
mechanisms for scheduling under the assumption that routers are time
synchronized. The most effective mechanisms for delay minimization involve
per-flow resource allocation.Segment Routing (SR) is a forwarding paradigm that allows encoding forwarding
instructions in the packet in a stack data structure, rather than being
programmed into the routers. The SR instructions are contained within a packet
in the form of a first-in first-out stack dictating the forwarding decisions of
successive routers. Segment routing may be used to choose a path sufficiently
short to be capable of providing sufficiently low end- to-end latency but does
not influence the queueing of individual packets in each router along that patTSN is required for networks transporting time sensitive traffic,
that is, packets that are required to be delivered to their final
destination by a given time.One efficient data structure for inserting local deadlines into
the headers is a “stack”, similar to that used in Segment Routing to
carry forwarding instructions. The number of deadline values in the
stack equals the number of routers the packet needs to traverse in
the network, and each deadline value corresponds to a specific
router. The Top-of-Stack (ToS) corresponds to the first router’s
deadline while the Bottom-of-Stack (BoS) refers to the last’s. All
local deadlines in the stack are later or equal to the current time
(upon which all routers agree), and times closer to the ToS are
always earlier or equal to times closer to the BoS.The ingress router inserts the deadline stack into the packet
headers; no other router needs to be aware of the requirements of the
time sensitive flows. Hence admitting a new flow only requires
updating the information base of the ingress router.MPLS LSRs that expose the Top of Stack (ToS) label can also inspect the
associated “deadline” carried in the packet (either in MPLS stack or after BoS).A number of different time formats commonly used in networking applications
and can be used to encode the local deadlines.For the forwarding sub-entry we could adopt like SR-MPLS standard
32-bit MPLS labels (which contain a 20-bit label and BoS bit), and
thus SR-TSN stack entries could be 64-bits in size comprising a 32-bit
MPLS label and the aforementioned nonstandard 32-bit timestamp.Alternatively, an SR-TSN stack entry could be 96 bits in length
comprising a 32-bit MPLS label and either of the standardized 64-bit
timestamps.The Network Service Header (NSH) can be embedded in an Extended Header (EH) to
support the Path ID and any metadata that needs to be carried and exchanged between
Service Function Forwarders (SFFs).A reference to the NSH SFC use case is defined in .In SR, an ingress node steers a packet through an ordered list of instructions,
called “segments”. Each one of these instructions represents a
function to be called at a specific location in the network. A
function is locally defined on the node where it is executed and may
range from simply moving forward in the segment list to any complex
user-defined behavior.Network Programming combines Segment Routing (SR) functions to achieve a
networking objective that goes beyond mere packet routing.It may be desirable to encode a pointers to function and its function-arguments
within an MPLS packet transport header. For example, in MPLS we can encode the
FUNC::ARGs within the label stack or after the bottom of stack to support the
equivalent of FUNC::ARG in SRv6 as described in .Application-aware Networking (APN) allows application-aware information (i.e.,
APN attribute) including APN identification (ID) and/or APN parameters (e.g.
network performance requirements) to be encapsulated at network edge devices
and carried in packets traversing an APN domain in order to facilitate service
provisioning, perform fine-granularity traffic steering and network resource
adjustment. To support APN in MPLS networks, mechanisms are needed to hold the
APN attribute.Two or more of the aforementioned use cases MAY co-exist in the same packet.
Some examples of such usecases are described below.IOAM may provide key functions with network slicing to help ensure that
critical network slice SLOs are being met by the network provider.In such a case, IOAM is able collect key performance measurement parameters of
network slice traffic flows as it traverses the transport network.This may require, in addition to carrying a specific network slice selector
(e.g., GISS), the MPLS network slice packets may have to also carry IOAM
ancillary data.Note that the IOAM ancillary data may have to be modified, and updated on
some/all LSRs traversed by the network slice MPLS packets.IOAM operation may also be desirable on MPLS packets that carry time-sensitive
related data. Similarly, this may require the presence of multiple ancillary data
(whether In-stack or Post-stack ancillary data) to be present in the same MPLS packet.This document has no IANA actions.This document introduces no new security considerations.The authors gratefully acknowledge the input of the members of the
MPLS Open Design Team.The following individuals contributed to this document:Key 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Framework for IETF Network SlicesOld Dog ConsultingIndependentJuniper NetworksNokiaNTTFutureweiTelefonicaMicrosoft Inc. This document describes network slicing in the context of networks
built from IETF technologies. It defines the term "IETF Network
Slice" and establishes the general principles of network slicing in
the IETF context.
The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network
Slice, the necessary system components and interfaces, and how
abstract requests can be mapped to more specific technologies. The
document also discusses related considerations with monitoring and
security.
This document also provides definitions of related terms to enable
consistent usage in other IETF documents that describe or use aspects
of IETF Network Slices.
Data Fields for In-situ OAMCisco Systems, Inc.ThoughtspotHuawei In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet
traverses a path in the network. This document discusses the data
fields and associated data types for in-situ OAM. In-situ OAM data
fields can be encapsulated into a variety of protocols such as NSH,
Segment Routing, Geneve, or IPv6. In-situ OAM can be used to
complement OAM mechanisms based on, e.g., ICMP or other types of
probe packets.
MPLS Data Plane Encapsulation for In-situ OAM DataCisco Systems, Inc.Cisco Systems, Inc.Cisco Systems, Inc.Cisco Systems, Inc.ComcastComcast In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the data packet while the
packet traverses a path between two nodes in the network. This
document defines how IOAM data fields are transported with MPLS data
plane encapsulation using new Generic Associated Channel (G-ACh).
MPLS Data Plane Encapsulation for In-situ OAM DataCisco SystemsCisco SystemsCisco SystemsComcastOrangeComcast In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the data packet while the
packet traverses a path between two nodes in the network. This
document defines how IOAM data fields are transported with MPLS data
plane encapsulation using new Generic Associated Channel (G-ACh).
Realizing Network Slices in IP/MPLS NetworksJuniper NetworksJuniper NetworksComcastEricssonEricssonZTE CorporationZTE CorporationVolta NetworksTelefonicaNokiaVerizon Network slicing provides the ability to partition a physical network
into multiple logical networks of varying sizes, structures, and
functions so that each slice can be dedicated to specific services or
customers. Network slices need to co-exist on the same network while
ensuring slice elasticity in terms of network resource allocation.
The Differentiated Service (Diffserv) model allows for carrying
multiple services on top of a single physical network by relying on
compliant domains and nodes to provide forwarding treatment
(scheduling and drop policy) on to packets that carry the respective
Diffserv code point. This document adopts a similar approach to
Diffserv and proposes a scalable approach to realize network slicing
in IP/MPLS networks. The solution does not mandate Diffserv to be
enabled in the network to provide a specific forwarding treatment,
but can co-exist with and complement it when enabled.
Multi-purpose Special Purpose Label for Forwarding ActionsJuniper NetworksJuniper NetworksJuniper NetworksBroadcom A Slice Selector is packet metadata that dictates the packet's
forwarding handling in order to conform to its slice requirements.
There are multiple proposals for carrying slice selectors in MPLS
networks. One of the more practical proposals is the "Global
Identifier for Slice Selector" (GISS). Global uniqueness requires
the GISS label be identified as such, via a special purpose label
(ideally a base special purpose label (bSPL)). However, bSPLs are a
precious commodity, and there are many requests for them. This
document serves two purposes: to define a bSPL for carrying a GISS,
and to show how this bSPL can consolidate many current requests for
special purpose labels while carrying associated data compactly and
efficiently.
Carrying Virtual Transport Network Identifier in MPLS PacketHuawei TechnologiesHuawei Technologies A Virtual Transport Network (VTN) is a virtual network which has a
customized network topology and a set of dedicated or shared network
resources allocated from the underlying network infrastructure.
Multiple VTNs can be created by network operator for using as the
underlay for one or a group of VPNs services to provide enhanced VPN
(VPN+) services. In packet forwarding, some fields in the data
packet needs to be used to identify the VTN the packet belongs to, so
that the VTN-specific processing can be executed.
This document proposes a mechanism to carry the VTN-ID in an MPLS
packet to identify the VTN the packet belongs to. The procedure for
processing the VTN ID is also specified.
Using Entropy Label for Network Slice Identification in MPLS networks.OrangeCisco Systems, Inc.NokiaJuniper NetworksJuniper NetworksVerizon This document defines a solution to encode a slice identifier in MPLS
in order to distinguish packets that belong to different slices, to
allow enforcing per network slice policies (.e.g, Qos).
The slice identification is independent of the topology. It allows
for QoS/DiffServ policy on a per slice basis in addition to the per
packet QoS/DiffServ policy provided by the MPLS Traffic Class field.
In order to minimize the size of the MPLS stack and to ease
incremental deployment the slice identifier is encoded as part of the
Entropy Label.
This document also extends the use of the TTL field of the Entropy
Label in order to provide a flexible set of flags called the Entropy
Label Control field.
Multiprotocol Label Switching ArchitectureThis document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]Introducing Resource Awareness to SR SegmentsHuawei TechnologiesFuturewei TechnologiesKDDI CorporationChina TelecomChina MobileChina MobileCisco Systems This document describes the mechanism to associate network resource
attributes to Segment Routing Identifiers (SIDs). Such SIDs are
referred to as resource-aware SIDs in this document. The resource-
aware SIDs retain their original forwarding semantics, but with the
additional semantics to identify the set of network resources
available for the packet processing action. The resource-aware SIDs
can therefore be used to build SR paths or virtual networks with a
set of reserved network resources. The proposed mechanism is
applicable to both segment routing with MPLS data plane (SR-MPLS) and
segment routing with IPv6 data plane (SRv6).
MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.Segment Routing over IPv6 (SRv6) Network ProgrammingThe Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.