draft-ietf-mpls-mna-usecases-10.txt   draft-ietf-mpls-mna-usecases-11.txt 
MPLS Working Group T. Saad MPLS Working Group T. Saad
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational K. Makhijani Intended status: Informational K. Makhijani
Expires: 21 December 2024 Independent Expires: 12 January 2025 Independent
H. Song H. Song
Futurewei Technologies Futurewei Technologies
G. Mirsky G. Mirsky
Ericsson Ericsson
19 June 2024 11 July 2024
Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data
draft-ietf-mpls-mna-usecases-10 draft-ietf-mpls-mna-usecases-11
Abstract Abstract
This document presents use cases that have a common feature in that This document presents use cases that have a common feature in that
they may be addressed by encoding network action indicators and they may be addressed by encoding network action indicators and
associated ancillary data within MPLS packets. There are interest in associated ancillary data within MPLS packets. There is interest in
extending the MPLS data plane to carry such indicators and ancillary extending the MPLS data plane to carry such indicators and ancillary
data to address the use cases that are described in this document. data to address the use cases that are described in this document.
The use cases described in this document are not an exhaustive set, The use cases described in this document are not an exhaustive set,
but rather the ones that are actively discussed by members of the but rather the ones that are actively discussed by members of the
IETF MPLS, PALS, and DetNet working groups. IETF MPLS, PALS, and DetNet working groups.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 December 2024. This Internet-Draft will expire on 12 January 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 16 skipping to change at page 3, line 16
from the MNA framework [I-D.ietf-mpls-mna-fwk]. Supporting a from the MNA framework [I-D.ietf-mpls-mna-fwk]. Supporting a
solution of the general MNA framework provides a common foundation solution of the general MNA framework provides a common foundation
for future network actions that can be exercised in the MPLS data for future network actions that can be exercised in the MPLS data
plane. plane.
1.1. Terminology 1.1. Terminology
The following terminology is used in the document: The following terminology is used in the document:
RFC 9543 Network Slice RFC 9543 Network Slice
is interpreted as defined in [RFC9543]. Furthermore, in this is interpreted as defined in [RFC9543]. Furthermore, this
document, the term "network slice" is used interchangeably as a document uses "network slice" interchangeably as a shorter version
shorter version of RFC 9543 Network Slice term. of the RFC 9543 Network Slice term.
The MPLS Ancillary Data (AD) classified as: The MPLS Ancillary Data (AD) is classified as:
* residing within the MPLS label stack and referred to as In * residing within the MPLS label stack and referred to as In
Stack Data (ISD), and Stack Data (ISD), and
* residing after the Bottom of Stack (BoS) and referred to as * residing after the Bottom of Stack (BoS) and referred to as
Post Stack Data (PSD). Post Stack Data (PSD).
1.2. Conventions used in this document 1.2. Conventions used in this document
1.2.1. Acronyms and Abbreviations 1.2.1. Acronyms and Abbreviations
skipping to change at page 4, line 10 skipping to change at page 4, line 10
PW: Pseudowire PW: Pseudowire
BoS: Bottom of Stack BoS: Bottom of Stack
ToS: Top of Stack ToS: Top of Stack
NSH: Network Service Header NSH: Network Service Header
FRR: Fast Reroute FRR: Fast Reroute
IOAM: In-situ Operations, Administration, and Mantenance IOAM: In-situ Operations, Administration, and Maintenance
G-ACh: Generic Associated Channel G-ACh: Generic Associated Channel
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switch Router LSR: Label Switch Router
NRP: Network Resource Partition NRP: Network Resource Partition
AMM: Alternative Marking Method AMM: Alternative Marking Method
2. Use Cases 2. Use Cases
2.1. No Further Fastreroute 2.1. No Further Fastreroute
MPLS Fast Reroute [RFC4090], [RFC5286] and [RFC7490] is a useful and MPLS Fast Reroute [RFC4090], [RFC5286] and [RFC7490] is a useful and
widely deployed tool for minimizing packet loss in the case of a link widely deployed tool for minimizing packet loss in the case of a link
or node failure. or node failure.
Several cases exist where, once a Fast Reroute (FRR) has taken place Several cases exist where, once a Fast Reroute (FRR) has taken place
in an MPLS network and resulted in rerouting a packet away from the in an MPLS network and a packet is rerouted away from the failure, a
failure, a second FRR impacts the same packet on another node, and second FRR impacts the same packet on another node and may result in
may result in traffic disruption. traffic disruption.
In such a case, the packet impacted by multiple FRR events may In such a case, the packet impacted by multiple FRR events may
continue to loop between the label switch routers (LSRs) that continue to loop between the label switch routers (LSRs) that
activated FRR until the packet's TTL expires. This can lead to link activated FRR until the packet's TTL expires. That can lead to link
congestion and further packet loss. To avoid that situation, packets congestion and further packet loss. To avoid that situation, packets
that have been redirected by FRR will be marked using MNA to preclude that FRR has redirected will be marked using MNA to preclude further
further FRR processing. FRR processing.
2.2. Applicability of Hybrid Measurement Methods 2.2. Applicability of Hybrid Measurement Methods
MNA can be used to carry information essential for collecting MNA can be used to carry information essential for collecting
operational information and measuring various performance metrics operational information and measuring various performance metrics
that reflect the experience of the packet marked by MNA. Optionally, that reflect the experience of the packet marked by MNA. Optionally,
the operational state and telemetry information collected on the LSR the operational state and telemetry information collected on the LSR
may be transported using MNA techniques. may be transported using MNA techniques.
2.2.1. In-situ OAM 2.2.1. In-situ OAM
In-situ Operations, Administration, and Maintenance (IOAM), defined In-situ Operations, Administration, and Maintenance (IOAM), defined
in [RFC9197] and [RFC9326], might be used to collect operational and in [RFC9197] and [RFC9326], might be used to collect operational and
telemetry information while a packet traverses a particular path in a telemetry information while a packet traverses a particular path in a
network domain. network domain.
IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop
(HbH). In I2E mode, only the encapsulating and decapsulating nodes (HbH). In I2E mode, only the encapsulating and decapsulating nodes
will process IOAM data fields. In HbH mode, the encapsulating and will process IOAM data fields. In HbH mode, the encapsulating and
decapsulating nodes, as well as intermediate IOAM-capable nodes, decapsulating nodes and intermediate IOAM-capable nodes process IOAM
process IOAM data fields. The IOAM data fields, defined in data fields. The IOAM data fields, defined in [RFC9197], can be used
[RFC9197], can be used to derive the operational state of the network to derive the operational state of the network experienced by the
experienced by the packet with the IOAM Header that traversed the packet with the IOAM Header that traversed the path through the IOAM
path through the IOAM domain. domain.
Several IOAM Option-Types have been defined: Several IOAM Option-Types have been defined:
* Pre-allocated Trace * Pre-allocated Trace
* Incremental Trace * Incremental Trace
* Edge-to-Edge * Edge-to-Edge
* Proof-of-Transit * Proof-of-Transit
skipping to change at page 6, line 8 skipping to change at page 6, line 8
[RFC9342]) is an example of a hybrid performance measurement method [RFC9342]) is an example of a hybrid performance measurement method
([RFC7799]) that can be used in the MPLS network to measure packet ([RFC7799]) that can be used in the MPLS network to measure packet
loss and packet delay performance metrics. [RFC8957] defined the loss and packet delay performance metrics. [RFC8957] defined the
Synonymous Flow Label framework to realize AMM in the MPLS network. Synonymous Flow Label framework to realize AMM in the MPLS network.
The MNA is an alternative mechanism that can be used to support AMM The MNA is an alternative mechanism that can be used to support AMM
in the MPLS network. in the MPLS network.
2.3. Network Slicing 2.3. Network Slicing
An RFC 9543 Network Slice service ([RFC9543]) provides connectivity An RFC 9543 Network Slice service ([RFC9543]) provides connectivity
coupled with a set of network resource commitments and is expressed coupled with network resource commitments and is expressed in terms
in terms of one or more connectivity constructs. [RFC9543] also of one or more connectivity constructs. [RFC9543] also defines a
defines a Network Resource Partition (NRP) Policy as a policy Network Resource Partition (NRP) Policy as a policy construct that
construct that enables the instantiation of mechanisms to support one enables the instantiation of mechanisms to support one or more
or more network slice services. The packets associated with an NRP network slice services. The packets associated with an NRP may carry
may carry a marking in their network layer header to identify this a marking in their network layer header to identify this association,
association, which is referred to as an NRP Selector. The NRP referred to as an NRP Selector. The NRP Selector maps a packet to
Selector is used to map a packet to the associated set of network the associated network resources and provides the corresponding
resources and provide the corresponding forwarding treatment onto the forwarding treatment onto the packet.
packet.
A router that requires the forwarding of a packet that belongs to an A router that requires the forwarding of a packet that belongs to an
NRP may have to decide on the forwarding action to take based on NRP may have to decide on the forwarding action to take based on
selected next-hop(s), and the forwarding treatment (e.g., scheduling selected next-hop(s), and the forwarding treatment (e.g., scheduling
and drop policy) to enforce based on the associated per-hop behavior. and drop policy) to enforce based on the associated per-hop behavior.
In this case, routers that forward traffic over a physical link In this case, routers that forward traffic over a physical link
shared by multiple NRPs need to identify the NRP to which the packet shared by multiple NRPs need to identify the NRP to which the packet
belongs to enforce their respective forwarding actions and belongs to enforce their respective forwarding actions and
treatments. treatments.
MNA technologies can be used to signal actions for MPLS packets and MNA technologies can signal actions for MPLS packets and carry data
carry data essential for these actions. For example, MNA can carry essential for these actions. For example, MNA can carry the NRP
the NRP Selector [I-D.ietf-teas-ns-ip-mpls] in MPLS packets. Selector [I-D.ietf-teas-ns-ip-mpls] in MPLS packets.
2.4. NSH-based Service Function Chaining 2.4. NSH-based Service Function Chaining
[RFC8595] describes how Service Function Chaining can be realized in [RFC8595] describes how Service Function Chaining can be realized in
an MPLS network by emulating the Network Service Header (NSH) using an MPLS network by emulating the Network Service Header (NSH) using
only MPLS label stack elements. only MPLS label stack elements.
The approach in [RFC8595] introduces some limitations that are The approach in [RFC8595] introduces some limitations discussed in
discussed in [I-D.lm-mpls-sfc-path-verification]. This approach, [I-D.lm-mpls-sfc-path-verification]. This approach, however, can
however, can benefit from the framework introduced with MNA in benefit from the framework introduced with MNA in
[I-D.ietf-mpls-mna-fwk]. [I-D.ietf-mpls-mna-fwk].
MNA can be used to extend NSH emulation using MPLS labels [RFC8595] MNA can be used to extend NSH emulation using MPLS labels [RFC8595]
to support the functionality of NSH Context Headers, whether fixed or to support the functionality of NSH Context Headers, whether fixed or
variable-length. For example, MNA could support Flow ID [RFC9263] variable-length. For example, MNA could support Flow ID [RFC9263]
that may be used for load-balancing among Service Function Forwarders that may be used for load-balancing among Service Function Forwarders
and/or the Service Functions within the same Service Function Path. and/or the Service Functions within the same Service Function Path.
2.5. Network Programming 2.5. Network Programming
In Segment Routing (SR), an ingress node steers a packet through an In Segment Routing (SR), an ingress node steers a packet through an
ordered list of instructions called "segments". Each one of these ordered list of instructions called "segments". Each of these
instructions represents a function to be called at a specific instructions represents a function to be called at a specific
location in the network. A function is locally defined on the node 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 where it is executed and may range from simply moving forward in the
segment list to any complex user-defined behavior. segment list to any complex user-defined behavior.
Network Programming combines SR functions to achieve a networking Network Programming combines SR functions to achieve a networking
objective that goes beyond mere packet routing. objective beyond mere packet routing.
Encoding a pointer to a function and its arguments within an MPLS Encoding a pointer to a function and its arguments within an MPLS
packet transport header may be desirable. MNA can be used to encode packet transport header may be desirable. MNA can be used to encode
the FUNC::ARGs to support the functional equivalent of FUNC::ARG in the FUNC::ARGs to support the functional equivalent of FUNC::ARG in
SRv6 as described in [RFC8986]. SRv6 as described in [RFC8986].
3. Existing MPLS Use cases 3. Existing MPLS Use cases
There are several services that can be transported over MPLS networks Several services can be transported over MPLS networks today. These
today. These include providing Layer-3 (L3) connectivity (e.g., for include providing Layer-3 (L3) connectivity (e.g., for unicast and
unicast and multicast L3 services), and Layer-2 (L2) connectivity multicast L3 services), and Layer-2 (L2) connectivity (e.g., for
(e.g., for unicast Pseudowires (PWs), multicast E-Tree, and broadcast unicast Pseudowires (PWs), multicast E-Tree, and broadcast E-LAN L2
E-LAN L2 services). In those cases, the user service traffic is services). In those cases, the user service traffic is encapsulated
encapsulated as the payload in MPLS packets. as the payload in MPLS packets.
For L2 service traffic, it is possible to use Control Word (CW) For L2 service traffic, it is possible to use Control Word (CW)
[RFC4385] and [RFC5085] immediately after the MPLS header to [RFC4385] and [RFC5085] immediately after the MPLS header to
disambiguate the type of MPLS payload, prevent possible packet disambiguate the type of MPLS payload, prevent possible packet
misordering, and allow for fragmentation. In this case, the first misordering, and allow for fragmentation. In this case, the first
nibble the data that immediately follows after the MPLS BoS is set to nibble the data that immediately follows after the MPLS BoS is set to
0000b to identify the presence of PW CW. 0000b to identify the presence of PW CW.
In addition to providing connectivity to user traffic, MPLS may also In addition to providing connectivity to user traffic, MPLS may also
transport OAM data (e.g., over MPLS Generic Associated Channels transport OAM data (e.g., over MPLS Generic Associated Channels
(G-AChs) [RFC5586]). In this case, the first nibble of the data that (G-AChs) [RFC5586]). In this case, the first nibble of the data that
immediately follows after the MPLS BoS is set to 0001b. It indicates immediately follows after the MPLS BoS is set to 0001b. It indicates
the presence of a control channel associated witha PW, LSP, or the presence of a control channel associated with a PW, LSP, or
Section. Section.
Bit Index Explicit Replication (BIER) [RFC8296] traffic can also be Bit Index Explicit Replication (BIER) [RFC8296] traffic can also be
encapsulated over MPLS. In this case, BIER has defined 0101b as the encapsulated over MPLS. In this case, BIER has defined 0101b as the
value for the first nibble in the data that immediately appears after value for the first nibble in the data that immediately appears after
the bottom of the label stack for any BIER encapsulated packet over the bottom of the label stack for any BIER-encapsulated packet over
MPLS. MPLS.
For pseudowires, the Generic Associated Channel [RFC7212] uses the For pseudowires, the Generic Associated Channel [RFC7212] uses the
first four bits of the PW control word to provide the initial first four bits of the PW control word to provide the initial
discrimination between data packets and packets belonging to the discrimination between data packets and packets belonging to the
associated channel, as described in [RFC4385]. associated channel, as described in [RFC4385].
MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet
sub-layers, forwarding and service, are realized using the MPLS label sub-layers, forwarding, and service are realized using the MPLS label
stack, the DetNet Control Word [RFC8964] and DetNet Associated stack, the DetNet Control Word [RFC8964], and the DetNet Associated
Channel Header [RFC9546]. Channel Header [RFC9546].
It is expected that new use cases described in this document will It is expected that new use cases described in this document will
allow for the co-existance and backward compatibility with all such allow for the co-existence and backward compatibility with all such
existing MPLS services. existing MPLS services.
4. Co-existence of the MNA Use Cases 4. Co-existence of the MNA Use Cases
Two or more of the aforementioned use cases may co-exist in the same Two or more of the discussed cases may co-exist in the same packet.
packet. This may require the presence of multiple ancilary data That may require the presence of multiple ancillary data (whether In-
(whether In-stack or Post-stack ancillary data) to be present in the stack or Post-stack ancillary data) to be present in the same MPLS
same MPLS packet. packet.
For example, IOAM may provide key functions along with network For example, IOAM may provide essential functions along with network
slicing to help ensure that critical network slice SLOs are being met slicing to help ensure that critical network slice SLOs are being met
by the network provider. In this case, IOAM is able to collect key by the network provider. In this case, IOAM can collect key
performance measurement parameters of network slice traffic flow as performance measurement parameters of network slice traffic flow as
it traverses the transport network. it traverses the transport network.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
This document introduces no new security considerations. This document introduces no new security considerations.
7. Acknowledgement 7. Acknowledgement
The authors gratefully acknowledge the input of the members of the The authors gratefully acknowledge the input of the members of the
MPLS Open Design Team. Also, the authors sicerely thank Loa MPLS Open Design Team. Also, the authors sincerely thank Loa
Andersson, Xiao Min, and Jie Dong for thier thoughtful suggestions Andersson, Xiao Min, and Jie Dong for their thoughtful suggestions
and help in improving the document. and help in improving the document.
8. References 8. References
8.1. Informative References 8.1. Informative References
[I-D.ietf-mpls-mna-fwk] [I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNA) Framework", Work in Progress, Network Actions (MNA) Framework", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-fwk-08, 7 May 2024, Internet-Draft, draft-ietf-mpls-mna-fwk-09, 19 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-08>. mna-fwk-09>.
[I-D.ietf-teas-ns-ip-mpls] [I-D.ietf-teas-ns-ip-mpls]
Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli,
D., Halpern, J. M., Peng, S., Chen, R., Liu, X., D., Halpern, J. M., Peng, S., Chen, R., Liu, X.,
Contreras, L. M., Rokui, R., and L. Jalil, "Realizing Contreras, L. M., Rokui, R., and L. Jalil, "Realizing
Network Slices in IP/MPLS Networks", Work in Progress, Network Slices in IP/MPLS Networks", Work in Progress,
Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-ns-ip-mpls-04>. teas-ns-ip-mpls-04>.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
<https://www.rfc-editor.org/info/rfc9543>. <https://www.rfc-editor.org/info/rfc9543>.
[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations, [RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration, and Maintenance (OAM) for Deterministic Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the MPLS Data Plane", RFC 9546, Networking (DetNet) with the MPLS Data Plane", RFC 9546,
DOI 10.17487/RFC9546, February 2024, DOI 10.17487/RFC9546, February 2024,
<https://www.rfc-editor.org/info/rfc9546>. <https://www.rfc-editor.org/info/rfc9546>.
Appendix A. Use Cases for Continued Discussion Appendix A. Use Cases for Continued Discussion
A number of use cases for which MNA can provide a viable solution Several use cases for which MNA can provide a viable solution have
have been brought up. The discussion of these aspirational cases is been discussed. The discussion of these aspirational cases is
ongoing. ongoing.
A.1. Generic Delivery Functions A.1. Generic Delivery Functions
The Generic Delivery Functions (GDFs), defined in The Generic Delivery Functions (GDFs), defined in
[I-D.zzhang-intarea-generic-delivery-functions], provide a new [I-D.zzhang-intarea-generic-delivery-functions], provide a new
mechanism to support functions analogous to those supported through mechanism to support functions analogous to those supported through
the IPv6 Extension Headers mechanism. For example, GDF can support the IPv6 Extension Headers mechanism. For example, GDF can support
fragmentation/reassembly functionality in the MPLS network by using fragmentation/reassembly functionality in the MPLS network by using
the Generic Fragmentation Header. MNA can support GDF by placing a the Generic Fragmentation Header. MNA can support GDF by placing a
skipping to change at page 12, line 42 skipping to change at page 12, line 42
incoming packets, namely forwarding (where the packet should be sent) incoming packets, namely forwarding (where the packet should be sent)
and scheduling (when the packet should be sent). IEEE-802.1 Time and scheduling (when the packet should be sent). IEEE-802.1 Time
Sensitive Networking (TSN) and Deterministic Networking provide Sensitive Networking (TSN) and Deterministic Networking provide
several mechanisms for scheduling under the assumption that routers several mechanisms for scheduling under the assumption that routers
are time-synchronized. The most effective mechanisms for delay are time-synchronized. The most effective mechanisms for delay
minimization involve per-flow resource allocation. minimization involve per-flow resource allocation.
Segment Routing (SR) is a forwarding paradigm that allows encoding Segment Routing (SR) is a forwarding paradigm that allows encoding
forwarding instructions in the packet in a stack data structure forwarding instructions in the packet in a stack data structure
rather than being programmed into the routers. The SR instructions rather than being programmed into the routers. The SR instructions
are contained within a packet in the form of a First-in First-out are contained within a packet in the form of a First-in, First-out
stack dictating the forwarding decisions of successive routers. stack dictating the forwarding decisions of successive routers.
Segment routing may be used to choose a path sufficiently short to be Segment routing may be used to choose a path sufficiently short to be
capable of providing a bounded end-to-end latency but does not capable of providing a bounded end-to-end latency but does not
influence the queueing of individual packets in each router along influence the queueing of individual packets in each router along
that path. that path.
When carried over the MPLS data plane, a solution is required to When carried over the MPLS data plane, a solution is required to
enable the delivery of such packets that can be delivered to their enable the delivery of such packets that can be delivered to their
final destination within a given time budget. One approach to final destination within a given time budget. One approach to
address this use case in SR-MPLS was described in [I-D.stein-srtsn]. address this use case in SR-MPLS was described in [I-D.stein-srtsn].
skipping to change at page 13, line 19 skipping to change at page 13, line 19
carry forwarding instructions. The number of deadline values in the carry forwarding instructions. The number of deadline values in the
stack equals the number of routers the packet needs to traverse in stack equals the number of routers the packet needs to traverse in
the network, and each deadline value corresponds to a specific the network, and each deadline value corresponds to a specific
router. The Top-of-Stack (ToS) corresponds to the first router's router. The Top-of-Stack (ToS) corresponds to the first router's
deadline, while the MPLS BoS refers to the last. All local deadlines deadline, while the MPLS BoS refers to the last. All local deadlines
in the stack are later or equal to the current time (upon which all 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 routers agree), and times closer to the ToS are always earlier or
equal to times closer to the MPLS BoS. equal to times closer to the MPLS BoS.
The ingress router inserts the deadline stack into the packet The ingress router inserts the deadline stack into the packet
headers; no other router needs to be aware of the requirements of the headers; no other router needs to know the time-bound flows'
time-bound flows. Hence, admitting a new flow only requires updating requirements. Hence, admitting a new flow only requires updating the
the information base of the ingress router. ingress router's information base.
MPLS LSRs that expose the ToS label can also inspect the associated MPLS LSRs that expose the ToS label can also inspect the associated
"deadline" carried in the packet (either in the MPLS stack as ISD or "deadline" carried in the packet (either in the MPLS stack as ISD or
after BoS as PSD). after BoS as PSD).
Contributors' Addresses Contributors' Addresses
Loa Anderssen Loa Anderssen
Bronze Dragon Consulting Bronze Dragon Consulting
Email: loa@pi.nu Email: loa@pi.nu
 End of changes. 31 change blocks. 
66 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/