RFC 6391
Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
RFC 6391: Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network 🎀
okay bestie, this is RFC 6391 💖 It's a Standards Track doc from the IETF (Internet Engineering Task Force), published November 2011, with ISSN 2070-1721. The editor is S. Bryant, Ed. and the co-authors are C. Filsfils (Cisco Systems), U. Drafz (Deutsche Telekom), V. Kompella (Alcatel-Lucent), J. Regan (Alcatel-Lucent), and S. Amante (Level 3 Communications, LLC) 👑 The title block doesn't list any Obsoletes or Updates entries, so this one doesn't replace or update any other RFCs ✨
Abstract
okay so picture this 🌸 when a pseudowire is carrying a bunch of different flows, it can be super useful to send those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network 🛣️ most forwarding engines can already hash the MPLS label stack and use that to balance MPLS flows over ECMPs, and it's giving efficiency 💅
this doc describes a way to identify the flows, or flow groups, inside a pseudowire so that Label Switching Routers can balance flows more finely than just per pseudowire 🦋 the trick is an extra label in the MPLS label stack 🧚
Status of This Memo
this is an Internet Standards Track document 📜
this doc is a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741 🌈
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6391 💜
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please review those docs carefully, because they spell out your rights and restrictions for this document 📖 code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🎀
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. ECMP in Label Switching Routers ............................4
1.3. Flow Label .................................................4
2. Native Service Processing Function ..............................5
3. Pseudowire Forwarder ............................................6
3.1. Encapsulation ..............................................7
4. Signalling the Presence of the Flow Label .......................8
4.1. Structure of Flow Label Sub-TLV ............................9
5. Static Pseudowires ..............................................9
6. Multi-Segment Pseudowires .......................................9
7. Operations, Administration, and Maintenance (OAM) ..............10
8. Applicability of PWs Using Flow Labels .........................11
8.1. Equal Cost Multiple Paths .................................12
8.2. Link Aggregation Groups ...................................13
8.3. Multiple RSVP-TE Paths ....................................13
8.4. The Single Large Flow Case ................................14
8.5. Applicability to MPLS-TP ..................................15
8.6. Asymmetric Operation ......................................15
9. Applicability to MPLS LSPs .....................................15
10. Security Considerations .......................................16
11. IANA Considerations ...........................................16
12. Congestion Considerations .....................................16
13. Acknowledgements ..............................................17
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................181. Introduction ✨
a pseudowire (PW) [RFC3985] is normally carried over one single network path, even when there are multiple Equal Cost Multiple Paths (ECMPs) between the ingress and egress PW provider edge (PE) equipment [RFC4385] [RFC4928] 🛤️ that single path is required to preserve the characteristics of the emulated service. for example, it avoids misordering Structure-Agnostic Time Division Multiplexing over Packet (SAToP) PW packets [RFC4553], and it avoids subjecting packets to unusable inter-arrival times 😭 using one path to keep order is still the default mode of operation for a PW. the new capability in this document is an OPTIONAL mode 🦋 you'd turn it on when using ECMPs is known to be beneficial, and not harmful, to the operation of the PW 💅
some PWs carry huge amounts of IP traffic between routers 🚀 one example is using an Ethernet PW to create a virtual direct link between a pair of routers. those PWs can carry anywhere from hundreds of Mbps to Gbps of traffic 🔥 they only need packet ordering preserved within each individual transported IP flow. they don't need ordering preserved between all packets of all IP flows inside the pseudowire 🙈
being able to explicitly configure such a PW to use multiple ECMPs gives you better capacity planning, because statistically multiplexing lots of smaller flows is more efficient than multiplexing a smaller set of larger flows 📊✨
usually, forwarding hardware can tell that an IP payload is being carried directly by an MPLS label stack, and it can look at some fields in packets to build hash buckets for conversations or flows 🧠 but when the MPLS payload is a PW, an intermediate node has no idea what type of PW it's carrying 😵 so the forwarder at that intermediate node can only make an ECMP choice based on a hash of the MPLS label stack. when a PW is emulating a high-bandwidth trunk, hashing the label stack is too coarse for satisfying load balancing 💀 the ingress node, though, is in a special position: it can read the unencapsulated packet header to help spread flows across any available ECMPs, or even across any Loop-Free Alternates [RFC5286] 👑 this document defines a way to add granularity to the hashing of traffic running over PWs. it does that by introducing an additional label, chosen by the ingress node and placed at the bottom of the label stack 🎀
besides telling ECMP forwarding decisions about the flow structure, the mechanism in this document may also be used to pick flows for distribution over an IEEE 802.1AX-2008 (originally specified as IEEE 802.3ad-2000) Link Aggregation Group (LAG) that's been used in an MPLS network 🌈
NOTE: Although Ethernet is frequently referenced as a use case in this RFC, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. 🧚
1.1. Requirements Language 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖
1.2. ECMP in Label Switching Routers 🛣️
Label Switching Routers (LSRs) commonly hash the label stack, or some elements of it, to tell flows apart, and then use that hash to spread those flows over the available ECMPs in the network 🔀 the label at the bottom of the stack is usually the one most closely tied to the flow, so it normally gives the greatest entropy and is usually included in the hash 🍓 this document describes a way to add an extra Label Stack Entry (LSE) at the bottom of the stack, so the flows inside a PW can be load balanced over the available ECMPs 🦋 a similar design for general MPLS use has also been proposed [MPLS-ENTROPY]; see Section 9 of this document 💅
an alternative was considered: create a number of PWs and spread the flows across them. it was rejected for two reasons 🙅♀️
- it didn't introduce as much entropy as adding an additional LSE can.
- it required additional PWs to be set up and maintained.
1.3. Flow Label 🌸
an additional LSE [RFC3032] is interposed between the PW LSE and the control word or, if the control word isn't present, between the PW LSE and the PW payload 🧁 this extra LSE is called the flow LSE, and the label it carries is called the flow label 🎀
indivisible flows within the PW MUST be mapped to the same flow label by the ingress PE 💖 the flow label is what triggers the correct ECMP load-balancing behaviour in the packet switched network (PSN) ✨ when the egress PE receives the PW packet (and it knows a flow LSE is present), it throws the flow LSE away without processing it 🗑️
the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but other than that, the protocol doesn't constrain it 🍭
it's worth thinking about the Time to Live (TTL) value in the flow LSE [RFC3032] 🧠 the flow LSE sits at the bottom of the label stack, so even with penultimate hop popping, it will always be preceded by the PW label when it arrives at the PE. if an error condition makes the flow LSE the top of the stack, it might get examined like a normal LSE, and the packet might then be forwarded 😱 you can prevent that by setting the flow LSE TTL to 1, which forces the forwarder to discard the packet 🙅♀️ just note that setting the TTL to 1 regardless of the payload may be considered a departure from the TTL procedures defined in [RFC3032] that apply to the general MPLS case 👀
this document doesn't define a use for the Traffic Class (TC) field [RFC5462] (formerly known as the Experimental Use (EXP) bits [RFC3032]) in the flow label. future documents may define a use for those bits, so implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress 🫶🌈
2. Native Service Processing Function ✨
okay so the Native Service Processing (NSP) function [RFC3985] is a component of a PE that actually knows how the emulated service is structured 🧠, and it can take action on the service outside the scope of the PW 💅. here's the key part: the NSP in the ingress PE is REQUIRED to identify flows, or groups of flows within the service, and indicate the flow (group) identity of each packet as it gets passed to the pseudowire forwarder 🫶. for example, if the PW type is Ethernet, the NSP might parse the ingress Ethernet traffic and consider all of the IP traffic 👀. that traffic can then be sorted into flows by treating all traffic with the same source and destination address pair as one single indivisible flow 🦋. since this is an NSP function, the method used to identify a flow is outside the scope of the PW design by definition 🙈. and because the NSP is internal to the PE, the method of flow indication to the PW forwarder is outside the scope of this document too 💜.
3. Pseudowire Forwarder 🎀
The PW forwarder must be provided with a method of mapping flows to load-balanced paths 🛣️.
The forwarder must generate a label for the flow or group of flows 💖. How the flow label values are determined is outside the scope of this document 🤷♀️. however, the flow label allocated to a flow MUST NOT be an MPLS reserved label, and it SHOULD remain constant for the life of the flow 🔒. it is RECOMMENDED that the method chosen to generate the load-balancing labels introduce a high degree of entropy in their values 🌈. the goal is to maximise the entropy presented to the ECMP selection mechanism in the LSRs in the PSN, so the flows get distributed as evenly as possible over the available PSN ECMP ✨. the forwarder at the ingress PE prepends the PW control word (if applicable), and then pushes the flow label, followed by the PW label 🧚.
NOTE: Although this document does not attempt to specify any hash algorithms, it is suggested that any such algorithm should be based on the assumption that there will be a high degree of entropy in the values assigned to the flow labels 🍓.
the forwarder at the egress PE uses the pseudowire label to identify the pseudowire 🎯. from the context associated with the pseudowire label, the egress PE can determine whether a flow LSE is present 🕵️♀️. if a flow LSE is present, it MUST be checked to determine whether it carries a reserved label 🚨. if it is a reserved label, the packet is processed according to the rules associated with that reserved label, otherwise the LSE is discarded 🗑️.
all other PW forwarding operations are unmodified by the inclusion of the flow LSE 😌.
3.1. Encapsulation 🧁
the PWE3 Protocol Stack Reference Model modified to include flow LSE is shown in Figure 1 🍰.
+-------------+ +-------------+
| Emulated | | Emulated |
| Ethernet | | Ethernet |
| (including | Emulated Service | (including |
| VLAN) |<==============================>| VLAN) |
| Services | | Services |
+-------------+ +-------------+
| Flow | | Flow |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 1: PWE3 Protocol Stack Reference Modelthe encapsulation of a PW with a flow LSE is shown in Figure 2 📦.
+---------------------------+
| |
| Payload |
| | n octets
| |
+---------------------------+
| Optional Control Word | 4 octets
+---------------------------+
| Flow LSE | 4 octets
+---------------------------+
| PW LSE | 4 octets
+---------------------------+
| MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE)
+---------------------------+
Figure 2: Encapsulation of a Pseudowire with a Pseudowire Flow LSE4. Signalling the Presence of the Flow Label 📣
when using the signalling procedures in [RFC4447], a new Pseudowire Interface Parameter Sub-TLV, the Flow Label Sub-TLV (FL Sub-TLV), is used to synchronise the flow label states between the ingress and egress PEs 🔄.
the absence of an FL Sub-TLV indicates that the PE is unable to process flow labels 🙅♀️. an ingress PE that is using PW signalling and that does not send an FL Sub-TLV MUST NOT include a flow label in the PW packet 🚫. an ingress PE that is using PW signalling and that does not receive an FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet either 🚫. this preserves backwards compatibility with existing PW specifications 🫶.
a PE that wishes to send a flow label in a PW packet MUST include in its label mapping message an FL Sub-TLV with T = 1 (see Section 4.1) 📨.
a PE that is willing to receive a flow label MUST include in its label mapping message an FL Sub-TLV with R = 1 (see Section 4.1) 🙋♀️.
a PE that receives a label mapping message containing an FL Sub-TLV with R = 0 MUST NOT include a flow label in the PW packet ❌.
thus, a PE sending an FL Sub-TLV with T = 1 and receiving an FL Sub-TLV with R = 1 MUST include a flow label in the PW packet ✅. under all other combinations of FL Sub-TLV signalling, a PE MUST NOT include a flow label in the PW packet 🙅♀️.
the signalling procedures in [RFC4447] state that "Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored" 📜. the signalling procedure described here is therefore backwards compatible with existing implementations 💅.
note that what is signalled is the desire to include the flow LSE in the label stack 🫧. the value of the flow label is a local matter for the ingress PE, and the label value itself is not signalled 🤐.
4.1. Structure of Flow Label Sub-TLV 🧩
the structure of the Flow Label Sub-TLV is shown in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FL=0x17 | Length |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Label Sub-TLVwhere:
FL(value0x17) is the Flow Label Sub-TLV identifier assigned by IANA (see Section 11) 🏷️.Lengthis the length of the Sub-TLV in octets and is4📏.- when
T = 1, the PE is requesting the ability to send a PW packet that includes a flow label. whenT = 0, the PE is indicating that it will not send a PW packet containing a flow label 📤. - when
R = 1, the PE is able to receive a PW packet with a flow label present. whenR = 0, the PE is unable to receive a PW packet with the flow label present 📥. - Reserved bits MUST be zero on transmit and MUST be ignored on receive 🫧.
5. Static Pseudowires 🪐
if PWE3 signalling [RFC4447] is not in use for a PW, then whether the flow label is used MUST be identically provisioned in both PEs at the PW endpoints 🛠️. if there is no provisioning support for this option, the default behaviour is not to include the flow label 🙃.
6. Multi-Segment Pseudowires 🔗
the flow label mechanism described in this document works on multi-segment PWs without requiring modification to the Switching PEs (S-PEs) 🙌. that's because the flow LSE is transparent to the label swap operation, and because interface parameter Sub-TLV signalling is transitive 🧠.
7. Operations, Administration, and Maintenance (OAM) 🔍
the following OAM considerations apply to this method of load balancing 📋.
where the OAM is only to be used to perform a basic test to verify that the PWs have been configured at the PEs, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] messages may be sent using any load balance PW path, i.e., using any value for the flow label 🧪.
where it is required to verify that a pseudowire is fully functional for all flows, a VCCV [RFC5085] connectivity verification message MUST be sent over each ECMP path to the pseudowire egress PE 🔬. this solution may be difficult to achieve and scales poorly 😩. under these circumstances, it may be sufficient to send VCCV messages using any load balance pseudowire path, because if a failure occurs within the PSN, the failure will normally be detected and repaired by the PSN 🛡️. that is, the PSN's Interior Gateway Protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880], or IGP hello detection) and the IGP convergence will naturally modify the ECMP set of network paths between the ingress and egress PEs 🌊. hence, the PW is only impacted during the normal IGP convergence time ⏱️. note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090] [RFC5286] ⚡.
if the failure is related to the individual corruption of a Label Forwarding Information Base (LFIB) entry in a router, then only the network path using that specific entry is impacted 🎯. if the PW is load-balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or if all paths are tested 🎲. since testing all paths may present problems as noted above, other mechanisms to detect this type of error may need to be developed, such as a Label Switched Path (LSP) self-test technology 🤞.
to troubleshoot the MPLS PSN, including multiple paths, the techniques described in [RFC4378] and [RFC4379] can be used 🧰.
where the PW OAM is carried out of band (VCCV Type 2) [RFC5085], it is necessary to insert an "MPLS Router Alert Label" in the label stack 🚨. the resultant label stack is as follows:
+-------------------------------+
| |
| VCCV Message | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Flow LSE | 4 octets
+-------------------------------+
| PW LSE | 4 octets
+-------------------------------+
| Router Alert LSE | 4 octets
+-------------------------------+
| MPLS Tunnel LSE(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Use of Router Alert Labelnote that, depending on the number of labels hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load-balanced to a different path from that taken by the data packets with identical flow and PW labels 🌀.
8. Applicability of PWs Using Flow Labels ✨
okay bestie, so a node sitting inside the PSN can't do deep packet inspection (DPI) on the PW 🙈 because PW tech isn't self-describing. Only the ingress and egress PE devices know what the payload looks like. So this method is a statistical band-aid for load balancing, and it only works when the PE can tell the flows apart in the traffic coming in on the attachment circuit 💅
The methods in this doc are transparent to the PSN, so the core doesn't need any new capability at all. Literally nothing new for it to learn 🦋
Load balancing over multiple PSN paths becomes a need when the ratio between the PW access speed and the PSN's core link bandwidth is large (e.g., >= 10%). ATM and Frame Relay are unlikely to hit that, but Ethernet might, which is why this doc focuses on Ethernet. Other high-access-bandwidth PWs could get their own stuff later 🌈
This design makes sense for MPLS PWs where it's meaningful to break the packets handed to the ingress PE down into flows. The mechanism spreads flows within the PW across different network paths. So packets inside one flow still arrive in order (subject to normal IP delivery perturbations due to topology variation), but order is no longer kept for all packets sent over the PW. ngl that's the tradeoff 😭
It is not proposed to give each flow its own sequence number. So if you need sequence number support:
the flow label mechanism MUST NOT be used. 🚫
Where the Ethernet PW carries IP, the flows can be identified and mapped to an ECMP. Typical methods include hashing on the source and destination addresses, the protocol ID, and higher-layer flow-dependent fields like TCP/UDP ports, Layer 2 Tunneling Protocol version 3 (L2TPv3) Session IDs, etc. 💖
Where the Ethernet PW carries non-IP traffic, techniques used for link bundling between Ethernet switches may be reused. The catch is that the latency distribution would be larger than in the link bundle case, and whether that's acceptable is for further study 🧚 Of particular importance, the Ethernet control frames SHOULD always be mapped to the same PSN path to ensure in-order delivery. Main character energy for control frames ✨
8.1. Equal Cost Multiple Paths
ECMP in packet switched networks is statistical in nature 🎀 The mapping of flows to a particular path doesn't take into account the bandwidth of the flow being mapped, or the current bandwidth usage of the members of the ECMP set. This simplification works really well when flows are evenly spread over the ECMP set and there are a large number of flows that are low bandwidth relative to the paths. Random allocation of a flow to a path gives a good approximation of an even spread, as long as polarisation effects are avoided. The method defined here has the same statistical properties as an IP PSN, so it's giving familiar 💅
ECMP is a load-sharing mechanism based on sharing the load over a number of layer 3 paths through the PSN. Often, though, multiple links exist between a pair of LSRs that the IGP considers a single link. These are known as link bundles 🍓 The mechanism described here can also distribute the flows within a PW over the members of the link bundle, using the flow label value to identify candidate flows. How that mapping happens is outside the scope of this specification. Similar considerations apply to Link Aggregation Groups.
There's no mechanism currently defined to indicate the bandwidths in use by specific flows using the fields of the MPLS shim header 🙃 And since the semantics of the MPLS shim header are fully defined in [RFC3032] and [RFC5462], those fields can't be assigned semantics to carry this info. This document doesn't define any semantic for the TTL or TC fields of the label entry that carries the flow label. It does require that the flow label itself be selected with a high degree of entropy, which suggests the label value should not be overloaded with additional meaning in any later spec 🔥
A different type of load balancing is carrying a PW over a set of PSN links where the bandwidth of each member is less than the bandwidth of the PW. Proposals to address this have been made in the past [PWBONDING]. This kind of mechanism can be considered complementary to this one 🫶
8.2. Link Aggregation Groups
A Link Aggregation Group (LAG) bonds together several physical circuits between two adjacent nodes so they appear to higher-layer protocols as a single, higher-bandwidth "virtual" pipe 🌸 LAGs can coexist in various parts of a given network. One perk is that they reduce the number of routing and signalling protocol adjacencies between devices, which cuts down on control plane processing overhead. Same as with ECMP, the big problem with LAGs is that, because LAG load-distribution algorithms aren't perfectly efficient, one particular member of a LAG can end up congested. The mechanism proposed here may help produce a more uniform flow distribution ✨
The same considerations that require a flow to go over a single member of an ECMP set also apply to a member of a LAG.
8.3. Multiple RSVP-TE Paths
In some networks, it's desirable for a Label Edge Router (LER) to load-balance a PW across multiple Resource Reservation Protocol - Traffic Engineering (RSVP-TE) tunnels 👑 The flow label mechanism described in this document can give the LER the flow information and entropy it needs to do this kind of load balancing. An example is using the flow label mechanism in networks with a link bundle using the all ones component [RFC4201] 🦋
How the LER is configured to apply this type of ECMP is outside the scope of this document 🙈
8.4. The Single Large Flow Case
Clearly, the operator needs to make sure that the service offered using PW technology and this method doesn't exceed the maximum planned link capacity. The exception is when it can be guaranteed that the traffic conforms to the Internet traffic profile of a very large number of small flows 💅
If the NSP can't access enough info to tell flows apart, maybe because the protocol stack needs to be parsed further into the packet than it's able to go, then the functionality described here gives no benefit 😭 The most common case where a single flow dominates a PW is when it's used to transport enterprise traffic. Enterprise traffic might be one big TCP flow, or encrypted flows that these methods can't handle.
An operator has four options in these situations:
- The operator can choose to do nothing, and the system will work as it does without the flow label.
- The operator can make the customer aware that the service offering has a restriction on flow bandwidth, and police flows to that restriction. This lets customers offering multiple flows use a bigger fraction of their access bandwidth, while stopping one flow from eating a chunk of internal link bandwidth the operator considers excessive 💜
- The operator could configure the ingress PE to assign a constant flow label to all high-bandwidth flows, so that only one path gets affected by those flows.
- The operator could configure the ingress PE to assign a random flow label to all high-bandwidth flows, which minimises disruption to the network at the cost of out-of-order traffic to the user 🌈
The issues above are mitigated by two factors:
- Firstly, the customer of a high-bandwidth PW service has an incentive to get the best transport service 🔥 An inefficient use of the PSN leads to jitter and eventually to loss of the PW's payload, so they're motivated to keep things smooth.
- Secondly, the customer is usually able to tailor their applications to generate many flows in the PSN ✨ A well-known example is massive data transport between servers that use many parallel TCP sessions. Any transport protocol can do this: multiple UDP ports, multiple L2TPv3 Session IDs, or multiple Generic Routing Encapsulation (GRE) keys can be used to break a large flow into smaller pieces. This approach may also be applied to IPsec [RFC4301], where multiple Security Parameter Indexes (SPIs) may be allocated to the same security association 🫶
8.5. Applicability to MPLS-TP
The MPLS Transport Profile (MPLS-TP) [RFC5654] Requirement 44 says: "MPLS-TP MUST support mechanisms that ensure the integrity of the transported customer's service traffic as required by its associated Service Level Agreement (SLA). Loss of integrity may be defined as packet corruption, reordering, or loss during normal network conditions". 🧐
MPLS-TP also leans heavily on the fate sharing between OAM and data packets, and the flow LSE breaks that 😭 The flow-aware transport of a PW reorders packets, so it:
MUST NOT be deployed in a network conforming to MPLS-TP, unless these integrity requirements specified in the SLA can be satisfied. 🚫
8.6. Asymmetric Operation
The protocol defined here supports asymmetric inclusion of the flow LSE 🦋 Asymmetric operation can be expected when there's asymmetry in the bandwidth requirements, making it unprofitable for one PE to do the flow classification. It can also happen when that PE can't do the classification but can still receive flow labeled packets from its peer 💅 Asymmetric operation of the PW may also be needed when one PE has a high transmission bandwidth requirement, but needs to receive the entire PW on a single interface to run a processing operation that requires the context of the complete PW (for example, policing the egress traffic) 🎀
9. Applicability to MPLS LSPs
An extension of this technique creates a basis for hash diversity without having to peek below the label stack for IP traffic carried over Label Distribution Protocol (LDP) LSPs 🌸 The generalisation of this extension to MPLS has been described in [MPLS-ENTROPY]. This generalisation can be seen as a complementary, but distinct, approach from the technique described in this document. Similar considerations may apply to identifying flows and allocating flow label values, but the flow labels are imposed by different network components, and the signalling mechanisms are different 🧚
10. Security Considerations
Okay, this part is serious, so listen up 🚨 The PW generic security considerations in [RFC3985] and the security considerations for a specific PW type (for example, in the case of an Ethernet PW [RFC4448]) both apply. The security considerations in [RFC5920] also apply 🔐
Section 1.3 describes considerations that apply to the TTL value used in the flow LSE. Using a TTL value of one prevents the accidental forwarding of a packet based on the label value in the flow LSE. Please don't skip that bit, bestie 💀
11. IANA Considerations ✨
okay bestie, IANA maintains the registry "Pseudowire Name Spaces (PWE3)" 🎀 and inside it there's a sub-registry called "Pseudowire Interface Parameters Sub-TLV type Registry" 💅. IANA has already registered the Flow Label Sub-TLV type in there, and it's giving tidy little entry vibes 🦋:
Parameter ID Length Description Reference
------------------------------------------------------
0x17 4 Flow Label RFC 639112. Congestion Considerations 🌸
so the congestion considerations for PWs from [RFC3985] apply to this design too 🫶. no cap, that's the baseline.
the ability to explicitly configure a PW to use multiple ECMPs is seriously good for capacity planning 📊✨. like, if everything else stays the same, statistical multiplexing of lots of smaller flows is more efficient than having a few big flows. main character energy for sure 👑.
ngl, if classification into flows only happens on IP packets, then those flows behave under congestion exactly the way the IETF already defined for that packet type 💖. no extra congestion processing needed, periodt 💅.
BUT 😭 where non-IP flows get classified, PW congestion avoidance MUST be applied to each non-IP load balance group 🚨. that one is not optional bestie 🙈.
13. Acknowledgements 🧚
the authors wanted to thank Mary Barnes, Eric Grey, Kireeti Kompella, Joerg Kuechemann, Wilfried Maas, Luca Martini, Mark Townsley, Rolf Winter, and Lucy Yong 🫶💜 for their valuable comments on this document. iconic behaviour from the whole squad ✨.
14. References 📚
14.1. Normative References 💖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over
MPLS Networks", RFC 4448, April 2006.
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, June 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding
Equal Cost Multipath Treatment in MPLS Networks",
BCP 128, RFC 4928, June 2007.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085,
December 2007.14.2. Informative References 🦋
[MPLS-ENTROPY]
Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
Work in Progress, October 2011.
[PWBONDING] Stein, Y(J)., Mendelsohn, I., and R. Insler, "PW
Bonding", Work in Progress, November 2008.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for
Multi-Protocol Label Switching (MPLS) Operations and
Management (OAM)", RFC 4378, February 2006.
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification
for IP Fast Reroute: Loop-Free Alternates", RFC 5286,
September 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M.,
Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.Authors' Addresses 🎀
Stewart Bryant (editor)
Cisco Systems
250 Longwater Ave.
Reading RG2 6GB
United Kingdom
Phone: +44-208-824-8828
EMail: stbryant@cisco.com
Clarence Filsfils
Cisco Systems
Brussels
Belgium
EMail: cfilsfil@cisco.com
Ulrich Drafz
Deutsche Telekom
Muenster
Germany
EMail: Ulrich.Drafz@telekom.de
Vach Kompella
Alcatel-Lucent
EMail: vach.kompella@alcatel-lucent.com
Joe Regan
Alcatel-Lucent
EMail: joe.regan@alcatel-lucent.com
Shane Amante
Level 3 Communications, LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
EMail: shane@level3.net📦 where this page comes from
- ietf: rfc6391 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms