rfc9789v1.txt | rfc9789.txt | |||
---|---|---|---|---|
skipping to change at line 116 ¶ | skipping to change at line 116 ¶ | |||
set of network actions and information elements supporting additional | set of network actions and information elements supporting additional | |||
operational models and capabilities of MPLS networks. MNA solutions | operational models and capabilities of MPLS networks. MNA solutions | |||
derived from this framework are intended to address the requirements | derived from this framework are intended to address the requirements | |||
found in [RFC9613]. In addition, MNA may support actions that | found in [RFC9613]. In addition, MNA may support actions that | |||
overlap existing MPLS functionality. This may be beneficial for | overlap existing MPLS functionality. This may be beneficial for | |||
numerous reasons, such as making it more efficient to combine | numerous reasons, such as making it more efficient to combine | |||
existing functionality and new functions in the same MPLS packet. | existing functionality and new functions in the same MPLS packet. | |||
MPLS forwarding actions are instructions to MPLS routers to apply | MPLS forwarding actions are instructions to MPLS routers to apply | |||
additional actions when forwarding a packet. These might include | additional actions when forwarding a packet. These might include | |||
load-balancing a packet given its entropy, whether or not to perform | load-balancing a packet given its entropy, indicating whether or not | |||
Fast Reroute on a failure, and whether or not a packet has metadata | to perform Fast Reroute on a failure, and indicating whether or not a | |||
relevant to the forwarding actions along the path. | packet has metadata relevant to the forwarding actions along the | |||
path. | ||||
This document generalizes the concept of MPLS "forwarding actions" to | This document generalizes the concept of MPLS "forwarding actions" to | |||
"network actions" that include any action that an MPLS router is | "network actions" that include any action that an MPLS router is | |||
requested to take on the packet. Network actions include any MPLS | requested to take on the packet. Network actions include any MPLS | |||
forwarding actions but may also include other operations (such as | forwarding actions but may also include other operations (such as | |||
security functions, Operations, Administration, and Maintenance (OAM) | security functions, Operations, Administration, and Maintenance (OAM) | |||
procedures, etc.) that are not directly related to forwarding of the | procedures, etc.) that are not directly related to forwarding of the | |||
packet. MPLS network actions are always triggered by an MNA packet | packet. MPLS network actions are always triggered by an MNA packet | |||
but may have implications for subsequent traffic, including non-MNA | but may have implications for subsequent traffic, including non-MNA | |||
packets, as discussed in Section 2.4. | packets, as discussed in Section 2.4. | |||
skipping to change at line 159 ¶ | skipping to change at line 160 ¶ | |||
Action Indicator (NAI)", "Ancillary Data (AD)", and "Scope". | Action Indicator (NAI)", "Ancillary Data (AD)", and "Scope". | |||
In addition, this document defines the following terms: | In addition, this document defines the following terms: | |||
Network Action Sub-Stack (NAS): A set of related, contiguous LSEs in | Network Action Sub-Stack (NAS): A set of related, contiguous LSEs in | |||
the MPLS label stack for carrying information related to network | the MPLS label stack for carrying information related to network | |||
actions. The Label, TC, and TTL values in the LSEs in the NAS may | actions. The Label, TC, and TTL values in the LSEs in the NAS may | |||
be redefined, but the meaning of the S bit is unchanged. | be redefined, but the meaning of the S bit is unchanged. | |||
Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS | Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS | |||
contains a special label that indicates the start of the NAS. | contains a special-purpose label that indicates the start of the | |||
NAS. | ||||
1.3. Abbreviations | 1.3. Abbreviations | |||
+==============+=====================+=====================+ | +==============+=====================+=====================+ | |||
| Abbreviation | Meaning | Reference | | | Abbreviation | Meaning | Reference | | |||
+==============+=====================+=====================+ | +==============+=====================+=====================+ | |||
| AD | Ancillary Data | [RFC9613] | | | AD | Ancillary Data | [RFC9613] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| BIER | Bit Index Explicit | [RFC8279] | | | BIER | Bit Index Explicit | [RFC8279] | | |||
| | Replication | | | | | Replication | | | |||
skipping to change at line 200 ¶ | skipping to change at line 202 ¶ | |||
| I2E | Ingress to Egress | In the MNA context, | | | I2E | Ingress to Egress | In the MNA context, | | |||
| | | this document. | | | | | this document. | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| IGP | Interior Gateway | | | | IGP | Interior Gateway | | | |||
| | Protocol | | | | | Protocol | | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| ISD | In-Stack Data | [RFC9613] | | | ISD | In-Stack Data | [RFC9613] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| LSE | Label Stack Entry | [RFC3032] | | | LSE | Label Stack Entry | [RFC3032] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| LSP | Label Switched Path | | | ||||
+--------------+---------------------+---------------------+ | ||||
| MNA | MPLS Network Action | [RFC9613] | | | MNA | MPLS Network Action | [RFC9613] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| MSD | Maximum SID Depth | [RFC8491] | | | MSD | Maximum SID Depth | [RFC8491] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| NAI | Network Action | [RFC9613] | | | NAI | Network Action | [RFC9613] | | |||
| | Indicator | | | | | Indicator | | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| NAS | Network Action Sub- | This document | | | NAS | Network Action Sub- | This document | | |||
| | Stack | | | | | Stack | | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
skipping to change at line 224 ¶ | skipping to change at line 228 ¶ | |||
| | | Section 3.6 | | | | | Section 3.6 | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| RLD | Readable Label | This document | | | RLD | Readable Label | This document | | |||
| | Depth | | | | | Depth | | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| SID | Segment Identifier | [RFC8402] | | | SID | Segment Identifier | [RFC8402] | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| SPL | Special-Purpose | [RFC9017] | | | SPL | Special-Purpose | [RFC9017] | | |||
| | Label | | | | | Label | | | |||
+--------------+---------------------+---------------------+ | +--------------+---------------------+---------------------+ | |||
| TC | Traffic Class | | | ||||
+--------------+---------------------+---------------------+ | ||||
| TTL | Time to Live | | | ||||
+--------------+---------------------+---------------------+ | ||||
Table 1: Abbreviations | Table 1: Abbreviations | |||
2. Structure | 2. Structure | |||
An MNA solution specifies one or more network actions to apply to an | An MNA solution specifies one or more network actions to apply to an | |||
MPLS packet. These network actions and their ancillary data may be | MPLS packet. These network actions and their ancillary data may be | |||
carried in sub-stacks within the MPLS label stack and/or post-stack | carried in sub-stacks within the MPLS label stack and/or post-stack | |||
data. A solution must specify where the network action sub-stacks | data. A solution must specify where the network action sub-stacks | |||
occur in the label stack, if and how frequently they should be | occur in the label stack, if and how frequently they should be | |||
skipping to change at line 301 ¶ | skipping to change at line 309 ¶ | |||
Figure 1: A Label Stack with an Embedded Network Action Sub-Stack | Figure 1: A Label Stack with an Embedded Network Action Sub-Stack | |||
Certain network actions may also specify that data is carried after | Certain network actions may also specify that data is carried after | |||
the label stack. This is called post-stack data. The encoding of | the label stack. This is called post-stack data. The encoding of | |||
the post-stack data, if any, for a network action must be specified | the post-stack data, if any, for a network action must be specified | |||
in the document that defines the network action. If multiple network | in the document that defines the network action. If multiple network | |||
actions are present and have post-stack data, the ordering of their | actions are present and have post-stack data, the ordering of their | |||
post-stack data corresponds to the ordering of the network action | post-stack data corresponds to the ordering of the network action | |||
indicators. | indicators. | |||
As an example, post-stack data might appear as a label stack followed | As an example, a packet containing post-stack data might contain a | |||
by post-stack data, followed by the payload: | label stack followed by post-stack data, followed by the payload: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | TC |0| TTL | | | Label | TC |0| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | TC |1| TTL | | | Label | TC |1| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Post-Stack Data | | | Post-Stack Data | | |||
~ ~ | ~ ~ | |||
skipping to change at line 327 ¶ | skipping to change at line 335 ¶ | |||
Figure 2: A Label Stack Followed by Post-Stack Data | Figure 2: A Label Stack Followed by Post-Stack Data | |||
A solution must specify the order for network actions to be applied | A solution must specify the order for network actions to be applied | |||
to the packet for the actions to have consistent semantics. Since | to the packet for the actions to have consistent semantics. Since | |||
there are many possible orderings, especially with bit catalogs | there are many possible orderings, especially with bit catalogs | |||
(Section 3.5.1), the solution must provide an unambiguous | (Section 3.5.1), the solution must provide an unambiguous | |||
specification. The precise semantics of an action are dependent on | specification. The precise semantics of an action are dependent on | |||
the contents of the packet, including any ancillary data, and the | the contents of the packet, including any ancillary data, and the | |||
state of the router. | state of the router. | |||
This document assumes that the MPLS WG will select not more than one | This document assumes that the MPLS WG will select a single solution | |||
solution for the encoding of ISD and not more than one solution for | for the encoding of ISD and not more than one solution for the | |||
the encoding of PSD. | encoding of PSD. | |||
2.1. Scopes | 2.1. Scopes | |||
A network action may need to be processed by every node along the | A network action may need to be processed by every node along the | |||
path or some subset of the nodes along its path. Some of the scopes | path or some subset of the nodes along its path. Some of the scopes | |||
that an action may have are: | that an action may have are: | |||
* Hop by Hop (HbH): Every node along the path will perform the | * Hop by Hop (HbH): Every node along the path will perform the | |||
action. | action. | |||
skipping to change at line 416 ¶ | skipping to change at line 424 ¶ | |||
Readable Label Depth (ERLD). Readable Label Depth is the same | Readable Label Depth (ERLD). Readable Label Depth is the same | |||
concept, but it is generalized and not specifically associated with | concept, but it is generalized and not specifically associated with | |||
the Entropy Label (EL) or MNA. | the Entropy Label (EL) or MNA. | |||
ERLD is not redundant with RLD because ERLD specifies a value of zero | ERLD is not redundant with RLD because ERLD specifies a value of zero | |||
if a system does not support the Entropy Label. Since a system could | if a system does not support the Entropy Label. Since a system could | |||
reasonably support MNA or other MPLS functions and needs to advertise | reasonably support MNA or other MPLS functions and needs to advertise | |||
an RLD value but not support the Entropy Label, another advertised | an RLD value but not support the Entropy Label, another advertised | |||
value is required. | value is required. | |||
A node that pushes an NAS onto the label stack is responsible for | A node that pushes a NAS onto the label stack is responsible for | |||
ensuring that all nodes that are expected to process the NAS will | ensuring that all nodes that are expected to process the NAS will | |||
have the entire NAS within their RLD. A node SHOULD use signaling | have the entire NAS within their RLD. A node SHOULD use signaling | |||
(e.g., the signaling described in [RFC9088] and [RFC9089]) to | (e.g., the signaling described in [RFC9088] and [RFC9089]) to | |||
determine this. An exception might be, for example, when the node | determine this. An exception might be, for example, when the node | |||
has out-of-band knowledge that all nodes along the path do not have | has out-of-band knowledge that all nodes along the path do not have | |||
RLD limitations and thus could avoid the unnecessary overhead of | RLD limitations and thus could avoid the unnecessary overhead of | |||
using signaling. | using signaling. | |||
Per [RFC8662], a node that does not support EL will advertise a value | Per [RFC8662], a node that does not support EL will advertise a value | |||
of zero for its ERLD, so advertising ERLD alone does not suffice in | of zero for its ERLD, so advertising ERLD alone does not suffice in | |||
skipping to change at line 440 ¶ | skipping to change at line 448 ¶ | |||
then signaling can be avoided. If a node's ERLD and RLD values are | then signaling can be avoided. If a node's ERLD and RLD values are | |||
the same, it MAY only advertise ERLD for efficiency reasons. If a | the same, it MAY only advertise ERLD for efficiency reasons. If a | |||
node supports MNA but does not support EL, then it SHOULD advertise | node supports MNA but does not support EL, then it SHOULD advertise | |||
RLD unless it has out-of-band knowledge that no nodes in the domain | RLD unless it has out-of-band knowledge that no nodes in the domain | |||
have RLD restrictions. | have RLD restrictions. | |||
RLD is advertised by an IGP MSD-Type value of 3 and MAY be advertised | RLD is advertised by an IGP MSD-Type value of 3 and MAY be advertised | |||
as a Node MSD, Link MSD, or both. | as a Node MSD, Link MSD, or both. | |||
An MNA node MUST use the RLD determined by selecting the first | An MNA node MUST use the RLD determined by selecting the first | |||
advertised non-zero value from: | advertised non-zero value from the following: | |||
* The RLD advertised for the link | * The RLD advertised for the link | |||
* The RLD advertised for the node | * The RLD advertised for the node | |||
* The non-zero ERLD for the node | * The non-zero ERLD for the node | |||
A node's RLD is a function of its hardware capabilities and is not | A node's RLD is a function of its hardware capabilities and is not | |||
expected to depend on the specifics of the MNA solution. | expected to depend on the specifics of the MNA solution. | |||
skipping to change at line 466 ¶ | skipping to change at line 474 ¶ | |||
LSP. | LSP. | |||
3. Encoding | 3. Encoding | |||
Several possible ways to encode NAIs have been proposed. This | Several possible ways to encode NAIs have been proposed. This | |||
section summarizes the proposals and some considerations for the | section summarizes the proposals and some considerations for the | |||
various alternatives. | various alternatives. | |||
When network actions are carried in the MPLS label stack, then | When network actions are carried in the MPLS label stack, then | |||
regardless of their type, they are represented by a set of LSEs | regardless of their type, they are represented by a set of LSEs | |||
termed a Network Action Sub-Stack (NAS). An NAS consists of a | termed a Network Action Sub-Stack (NAS). A NAS consists of a | |||
special label, optionally followed by LSEs that specify which network | special-purpose label, optionally followed by LSEs that specify which | |||
actions are to be performed on the packet and the in-stack ancillary | network actions are to be performed on the packet and the in-stack | |||
data for each indicated network action. Different network actions | ancillary data for each indicated network action. Different network | |||
may be placed together in one NAS or may be carried in different sub- | actions may be placed together in one NAS or may be carried in | |||
stacks. | different sub-stacks. | |||
[RFC9613] requires that a solution not add unnecessary LSEs to the | [RFC9613] requires that a solution not add unnecessary LSEs to the | |||
sub-stack (see requirement 9 in Section 3.1 of [RFC9613]). | sub-stack (see requirement 9 in Section 3.1 of [RFC9613]). | |||
Accordingly, solutions should also make efficient use of the bits | Accordingly, solutions should also make efficient use of the bits | |||
within the sub-stack (except the S-bit), as inefficient use of the | within the sub-stack (except the S-bit), as inefficient use of the | |||
bits could result in the addition of unnecessary LSEs. | bits could result in the addition of unnecessary LSEs. | |||
3.1. The MNA Label | 3.1. The MNA Label | |||
The first LSE in a network action sub-stack contains a special label | The first LSE in a network action sub-stack contains a special- | |||
that indicates a network action sub-stack. A solution has several | purpose label that indicates a network action sub-stack. A solution | |||
choices for this special label. | has several choices for this special-purpose label. | |||
3.1.1. Existing Base SPL | 3.1.1. Existing Base SPL | |||
A solution may reuse an existing Base SPL (bSPL). If it elects to do | A solution may reuse an existing Base SPL (bSPL). If it elects to do | |||
so, it must explain how the usage is backward compatible, including | so, it must explain how the usage is backward compatible, including | |||
in the case where there is ISD. | in the case where there is ISD. | |||
If an existing inactive bSPL is selected that will not be backward | If an existing inactive bSPL is selected that will not be backward | |||
compatible, then it must first be retired per [RFC7274] and then | compatible, then it must first be retired per [RFC7274] and then | |||
reallocated. | reallocated. | |||
skipping to change at line 533 ¶ | skipping to change at line 541 ¶ | |||
If the solution elects to retain the TC and TTL fields, then the | If the solution elects to retain the TC and TTL fields, then the | |||
first LSE of the network action sub-stack would appear as described | first LSE of the network action sub-stack would appear as described | |||
in [RFC3032]: | in [RFC3032]: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | TC |S| TTL | | | Label | TC |S| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: A Label Stack Entry | Figure 3: A Label Stack Entry with TC and TTL Retained | |||
Label: Label value, 20 bits | Label: Label value, 20 bits | |||
TC: Traffic Class, 3 bits | TC: Traffic Class, 3 bits | |||
S: Bottom of Stack, 1 bit | S: Bottom of Stack, 1 bit | |||
TTL: Time To Live | TTL: Time To Live, 8 bits | |||
Further LSEs would be needed to encode NAIs. If a solution elects to | Further LSEs would be needed to encode NAIs. If a solution elects to | |||
retain the TC and TTL fields, it must address the requirement for the | retain the TC and TTL fields, it must address the requirement for the | |||
minimal number of LSEs. | minimal number of LSEs. | |||
3.2.2. TC and TTL Repurposed | 3.2.2. TC and TTL Repurposed | |||
If the solution elects to reuse the TC and TTL fields, then the first | If the solution elects to reuse the TC and TTL fields, then the first | |||
LSE of the network action sub-stack would appear as follows: | LSE of the network action sub-stack would appear as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label |x x x|S|x x x x x x x x| | | Label |x x x|S|x x x x x x x x| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4 | Figure 4: A Label Stack Entry with TC and TTL Repurposed | |||
Label: Label value, 20 bits | Label: Label value, 20 bits | |||
x: Bit available for use in solution definition | x: Bit available for use in solution definition | |||
S: Bottom of Stack, 1 bit | S: Bottom of Stack, 1 bit | |||
The solution may use more LSEs to contain NAIs. If a solution elects | The solution may use more LSEs to contain NAIs. If a solution elects | |||
to use more LSEs, it must address the requirement for the minimal | to use more LSEs, it must address the requirement for the minimal | |||
number of LSEs. | number of LSEs. | |||
3.3. Length of the NAS | 3.3. Length of the NAS | |||
skipping to change at line 606 ¶ | skipping to change at line 614 ¶ | |||
contained in a network action sub-stack. For example, a NAS might | contained in a network action sub-stack. For example, a NAS might | |||
contain Action A (HbH), Action B (HbH), and Action C (HbH). A | contain Action A (HbH), Action B (HbH), and Action C (HbH). A | |||
solution may alternately choose to have the scope encoded implicitly, | solution may alternately choose to have the scope encoded implicitly, | |||
based on the actions present in the network action sub-stack. For | based on the actions present in the network action sub-stack. For | |||
example, a NAS might contain the following actions with HbH scope: A, | example, a NAS might contain the following actions with HbH scope: A, | |||
B, and C. This choice may have performance implications as an | B, and C. This choice may have performance implications as an | |||
implementation might have to parse the network actions that are | implementation might have to parse the network actions that are | |||
present in a network action sub-stack only to discover that there are | present in a network action sub-stack only to discover that there are | |||
no actions for it to perform. | no actions for it to perform. | |||
For example, suppose that an NAS is embedded in a label stack at a | For example, suppose that a NAS is embedded in a label stack at a | |||
depth of six LSEs and the NAS contains three actions, each with | depth of six LSEs and the NAS contains three actions, each with | |||
Select scope. These actions are not applicable at the current node | Select scope. These actions are not applicable at the current node | |||
and should be ignored. If the scope is encoded explicitly with each | and should be ignored. If the scope is encoded explicitly with each | |||
action, then an implementation must parse each action. However, if | action, then an implementation must parse each action. However, if | |||
the scope is encoded as part of the NAS, then an implementation only | the scope is encoded as part of the NAS, then an implementation only | |||
needs to parse the start of the NAS and not individual actions. | needs to parse the start of the NAS and not individual actions. | |||
Solutions need to consider the order of scoped NAIs and their | Solutions need to consider the order of scoped NAIs and their | |||
associated AD within individual sub-stacks and the order of per-scope | associated AD within individual sub-stacks and the order of per-scope | |||
sub-stacks, so that network actions and the AD can be readily found | sub-stacks, so that network actions and the AD can be readily found | |||
skipping to change at line 662 ¶ | skipping to change at line 670 ¶ | |||
Opcodes are efficient if there are only one or two active network | Opcodes are efficient if there are only one or two active network | |||
actions. For example, if an opcode is 8 bits, then two active | actions. For example, if an opcode is 8 bits, then two active | |||
network actions could be encoded in 16 bits. However, if 16 actions | network actions could be encoded in 16 bits. However, if 16 actions | |||
are required, then opcodes would consume 128 bits. Opcodes are | are required, then opcodes would consume 128 bits. Opcodes are | |||
efficient at encoding a large number of possible actions. If only | efficient at encoding a large number of possible actions. If only | |||
the 256th action is to be selected, that still requires 8 bits. | the 256th action is to be selected, that still requires 8 bits. | |||
3.6. Encoding of Post-Stack Data | 3.6. Encoding of Post-Stack Data | |||
A solution may carry some NAI and AD as PSD. For ease of parsing, | A solution may carry NAI and AD as PSD. For ease of parsing, all AD | |||
all AD should be co-located with its NAI. | should be co-located with its NAI. | |||
If there are multiple instances of post-stack data, they should occur | If there are multiple instances of post-stack data, they should occur | |||
in the same order as their relevant network action sub-stacks and | in the same order as their relevant network action sub-stacks and | |||
then in the same order as their relevant network actions occur within | then in the same order as their relevant network actions occur within | |||
the network action sub-stacks. | the network action sub-stacks. | |||
3.6.1. First Nibble Considerations | 3.6.1. First Nibble Considerations | |||
The first nibble after the label stack has been used to convey | The first nibble after the label stack has been used to convey | |||
information in certain cases [RFC4385]. A consolidated view of the | information in certain cases [RFC4385]. A consolidated view of the | |||
uses of the first nibble is provided in [RFC9790]. | uses of the first nibble is provided in [RFC9790]. | |||
For example, in [RFC4928], this nibble is investigated to find out if | For example, in [RFC4928], this nibble is investigated to find out if | |||
it has the value "4" or "6". If it does not, it is assumed that the | it has the value "4" or "6". If it does not, it is assumed that the | |||
packet payload is not IPv4 or IPv6, and Equal-Cost Multipath (ECMP) | packet payload is not IPv4 or IPv6, and Equal-Cost Multipath (ECMP) | |||
is not performed. | is not performed. | |||
It should be noted that this is an inexact method. For example, an | It should be noted that this is an inexact method. For example, an | |||
Ethernet pseudowire without a control word might have "4" or "6" in | Ethernet pseudowire without a control word might have "4" or "6" in | |||
the first nibble and thus will be ECMP'ed. | the first nibble and thus will be subject to ECMP forwarding. | |||
Nevertheless, the method is implemented and deployed; it is used | Nevertheless, the method is implemented and deployed; it is used | |||
today and will be for the foreseeable future. | today and will be for the foreseeable future. | |||
The use of the first nibble for Bit Index Explicit Replication (BIER) | The use of the first nibble for Bit Index Explicit Replication (BIER) | |||
is specified in [RFC8296]. BIER sets the first nibble to 5. The | is specified in [RFC8296]. BIER sets the first nibble to 5. The | |||
same is true for a BIER payload as for any use of the first nibble: | same is true for a BIER payload as for any use of the first nibble: | |||
it is not possible to conclude that the payload is BIER even if the | it is not possible to conclude that the payload is BIER even if the | |||
first nibble is set to 5 because an Ethernet pseudowire without a | first nibble is set to 5 because an Ethernet pseudowire without a | |||
control word might begin with a 5. However, the BIER approach meets | control word might begin with a 5. However, the BIER approach meets | |||
the design goal of [RFC8296] to determine that the payload is IPv4, | the design goal of [RFC8296] to determine that the payload is IPv4, | |||
IPv6 or with the header of a pseudowire packet with a control word, | IPv6, or the header of a pseudowire packet with a control word, | |||
rather than being a payload belonging to a BIER or some other type of | rather than being a payload belonging to a BIER or some other type of | |||
packet. | packet. | |||
[RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001 | [RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001 | |||
as the control word for the pseudowire Associated Channel Header | as the control word for the pseudowire Associated Channel Header | |||
(ACH). | (ACH). | |||
A PSD solution should specify the contents of the first nibble, the | A PSD solution should specify the contents of the first nibble, the | |||
actions to be taken for the value, and the interaction with post- | actions to be taken for the value, and the interaction with post- | |||
stack data used concurrently by other MPLS applications. | stack data used concurrently by other MPLS applications. | |||
skipping to change at line 722 ¶ | skipping to change at line 730 ¶ | |||
processing each of the network actions in a packet. Each network | processing each of the network actions in a packet. Each network | |||
action must specify how it interacts with all other previously | action must specify how it interacts with all other previously | |||
defined network actions. Private network actions are network actions | defined network actions. Private network actions are network actions | |||
that are not publicly documented. Private network actions MUST be | that are not publicly documented. Private network actions MUST be | |||
included in the ordering of network actions, but the interactions of | included in the ordering of network actions, but the interactions of | |||
private actions with other actions are outside of the scope of this | private actions with other actions are outside of the scope of this | |||
document. | document. | |||
5. Definition of a Network Action | 5. Definition of a Network Action | |||
Network actions should be defined in a document that must contain: | A document defining a network action must contain the following: | |||
Name: The name of the network action. | Name: The name of the network action. | |||
Network Action Indicator: The bit position or opcode that indicates | Network Action Indicator: The bit position or opcode that indicates | |||
that the network action is active. | that the network action is active. | |||
Scope: The document should specify which nodes should perform the | Scope: Description of which nodes should perform the network action | |||
network action as described in Section 2.1. | as described in Section 2.1. | |||
State: The document should specify if the network action can modify | ||||
state in the network and, if so, the state that may be modified | ||||
and its side effects. | ||||
Required/Optional: The document should specify whether a node is | State: Indication of whether the network action can modify state in | |||
required to perform the network action. | the network and, if so, the state that may be modified and its | |||
side effects. | ||||
In-Stack Data: The number of LSEs of in-stack data, if any, and its | Required/Optional: Indication of whether a node is required to | |||
encoding. If this is of a variable length, then the solution must | perform the network action. | |||
specify how an implementation can determine this length without | ||||
implementing the network action. | ||||
Post-Stack Data: The encoding of post-stack data, if any. If this | In-Stack Data: The number of LSEs of in-stack data, if any, and the | |||
is of a variable length, then the solution must specify how an | encoding of the in-stack data. If the in-stack data is of a | |||
implementation can determine this length without implementing the | variable length, then the solution must specify how an | |||
implementation can determine the length without implementing the | ||||
network action. | network action. | |||
Post-Stack Data: The encoding of post-stack data, if any. If the | ||||
post-stack data is of a variable length, then the solution must | ||||
specify how an implementation can determine the length without | ||||
implementing the network action. | ||||
A solution should create an IANA registry for network actions. | A solution should create an IANA registry for network actions. | |||
6. Management Considerations | 6. Management Considerations | |||
Network operators will need to be cognizant of which network actions | Network operators will need to be cognizant of which network actions | |||
are supported by which nodes and will need to ensure that this is | are supported by which nodes and will need to ensure that this is | |||
signaled. Some solutions may require network-wide configuration to | signaled. Some solutions may require network-wide configuration to | |||
synchronize the use of the labels that indicate the start of an NAS. | synchronize the use of the labels that indicate the start of a NAS. | |||
Solution documents must clearly state what management considerations | Solution documents must clearly state what management considerations | |||
apply to the solutions they are describing. Solution documents must | apply to the solutions they are describing. Solution documents must | |||
describe mechanisms for performing network diagnostics in the | describe mechanisms for performing network diagnostics in the | |||
presence of MNAs. | presence of MNAs. | |||
7. Security Considerations | 7. Security Considerations | |||
An analysis of the security of MPLS systems is provided in [RFC5920], | An analysis of the security of MPLS systems is provided in [RFC5920], | |||
which also notes that the MPLS forwarding plane has no built-in | which also notes that the MPLS forwarding plane has no built-in | |||
security mechanisms. | security mechanisms. | |||
Central to the security of MPLS networks is operational security of | Central to the security of MPLS networks is operational security of | |||
the network, something that operators of MPLS networks are well | the network, something that operators of MPLS networks are well | |||
versed in. The deployment of link-level security (e.g., Media Access | versed in. The deployment of link-level security (e.g., [MACsec]) | |||
Control Security (MACsec) [MACsec]) prevents link traffic observation | prevents link traffic observation covertly acquiring the label stack | |||
covertly acquiring the label stack for an attack. This is | for an attack. This is particularly important in the case of a | |||
particularly important in the case of a network deploying MNA, | network deploying MNA, because the MNA information may be sensitive. | |||
because the MNA information may be sensitive. Thus, the | Thus, the confidentiality and authentication achieved through the use | |||
confidentiality and authentication achieved through the use of link- | of link-level security is particularly advantageous. | |||
level security is particularly advantageous. | ||||
Some additional proposals to add encryption to the MPLS forwarding | Some additional proposals to add encryption to the MPLS forwarding | |||
plane have been suggested [MPLS-OPP-SEC], but no mechanisms have been | plane have been suggested [MPLS-OPP-SEC], but no mechanisms have been | |||
agreed upon at the time of publication of this document. | agreed upon at the time of publication of this document. | |||
[MPLS-OPP-SEC] offers hop-by-hop security that encrypts the label | [MPLS-OPP-SEC] offers hop-by-hop security that encrypts the label | |||
stack and is functionally equivalent to that provided by MACsec | stack and is functionally equivalent to that provided by [MACsec]. | |||
[MACsec]. Alternatively, it also offers end-to-end encryption of the | Alternatively, it also offers end-to-end encryption of the MPLS | |||
MPLS payload with no cryptographic integrity protection of the MPLS | payload with no cryptographic integrity protection of the MPLS label | |||
label stack. | stack. | |||
Particular care is needed when introducing any end-to-end security | Particular care is needed when introducing any end-to-end security | |||
mechanism to allow an in-stack MNA solution that needs to employ on- | mechanism to allow an in-stack MNA solution that needs to employ on- | |||
path modification of the MNA data or where post-stack MNA data needs | path modification of the MNA data or where post-stack MNA data needs | |||
to be examined on-path. | to be examined on-path. | |||
A cornerstone of MPLS security is to protect the network from | A cornerstone of MPLS security is to protect the network from | |||
processing MPLS labels that originated outside the network. | processing MPLS labels that originated outside the network. | |||
Operators have considerable experience in excluding MPLS-encoded | Operators have considerable experience in excluding MPLS-encoded | |||
skipping to change at line 906 ¶ | skipping to change at line 914 ¶ | |||
DOI 10.17487/RFC9017, April 2021, | DOI 10.17487/RFC9017, April 2021, | |||
<https://www.rfc-editor.org/info/rfc9017>. | <https://www.rfc-editor.org/info/rfc9017>. | |||
[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements | [RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements | |||
for Solutions that Support MPLS Network Actions (MNAs)", | for Solutions that Support MPLS Network Actions (MNAs)", | |||
RFC 9613, DOI 10.17487/RFC9613, August 2024, | RFC 9613, DOI 10.17487/RFC9613, August 2024, | |||
<https://www.rfc-editor.org/info/rfc9613>. | <https://www.rfc-editor.org/info/rfc9613>. | |||
9.2. Informative References | 9.2. Informative References | |||
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area | ||||
networks-Media Access Control (MAC) Security", IEEE Std | ||||
802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26 | ||||
December 2018, | ||||
<https://ieeexplore.ieee.org/document/8585421>. | ||||
[MPLS-OPP-SEC] | [MPLS-OPP-SEC] | |||
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS | Farrel, A. and S. Farrell, "Opportunistic Security in MPLS | |||
Networks", Work in Progress, Internet-Draft, draft-ietf- | Networks", Work in Progress, Internet-Draft, draft-ietf- | |||
mpls-opportunistic-encrypt-03, 28 March 2017, | mpls-opportunistic-encrypt-03, 28 March 2017, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- | <https://datatracker.ietf.org/doc/html/draft-ietf-mpls- | |||
opportunistic-encrypt-03>. | opportunistic-encrypt-03>. | |||
[MSD] IANA, "IGP MSD-Types", | ||||
<https://www.iana.org/assignments/igp-parameters/>. | ||||
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | |||
Cost Multipath Treatment in MPLS Networks", BCP 128, | Cost Multipath Treatment in MPLS Networks", BCP 128, | |||
RFC 4928, DOI 10.17487/RFC4928, June 2007, | RFC 4928, DOI 10.17487/RFC4928, June 2007, | |||
<https://www.rfc-editor.org/info/rfc4928>. | <https://www.rfc-editor.org/info/rfc4928>. | |||
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | |||
RFC 5714, DOI 10.17487/RFC5714, January 2010, | RFC 5714, DOI 10.17487/RFC5714, January 2010, | |||
<https://www.rfc-editor.org/info/rfc5714>. | <https://www.rfc-editor.org/info/rfc5714>. | |||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
skipping to change at line 977 ¶ | skipping to change at line 994 ¶ | |||
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet | [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet | |||
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, | Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, | |||
January 2024, <https://www.rfc-editor.org/info/rfc9522>. | January 2024, <https://www.rfc-editor.org/info/rfc9522>. | |||
[RFC9790] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., Ed., | [RFC9790] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., Ed., | |||
Andersson, L., and J. Dong, "IANA Registry and Processing | Andersson, L., and J. Dong, "IANA Registry and Processing | |||
Recommendations for the First Nibble Following a Label | Recommendations for the First Nibble Following a Label | |||
Stack", RFC 9790, DOI 10.17487/RFC9790, May 2025, | Stack", RFC 9790, DOI 10.17487/RFC9790, May 2025, | |||
<https://www.rfc-editor.org/info/rfc9790>. | <https://www.rfc-editor.org/info/rfc9790>. | |||
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area | ||||
networks-Media Access Control (MAC) Security", IEEE Std | ||||
802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26 | ||||
December 2018, | ||||
<https://ieeexplore.ieee.org/document/8585421>. | ||||
[MSD] IANA, "IGP MSD-Types", | ||||
<https://www.iana.org/assignments/igp-parameters/>. | ||||
Acknowledgements | Acknowledgements | |||
This document is the result of work started in MPLS Open Design Team, | This document is the result of work started in MPLS Open Design Team, | |||
with participation by the MPLS, PALS, and DETNET Working Groups. | with participation by the MPLS, PALS, and DETNET Working Groups. | |||
The authors would like to thank Adrian Farrel for his contributions. | The authors would like to thank Adrian Farrel for his contributions. | |||
The authors would also like to thank John Drake, Toerless Eckert, and | The authors would also like to thank John Drake, Toerless Eckert, and | |||
Jie Dong for their comments. | Jie Dong for their comments. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 29 change blocks. | ||||
65 lines changed or deleted | 73 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |