RFC 5254
Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)
Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) 🎀
okay bestie, let's talk about RFC 5254 💖 It's titled Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3), and it was written by three editors: N. Bitar from Verizon, M. Bocci from Alcatel-Lucent, and L. Martini from Cisco Systems, Inc. It's an Informational document from the Network Working Group, dated October 2008. The title block doesn't list anything it obsoletes or updates, so it's a standalone document 🦋
Status of This Memo
This memo is here to give information to the Internet community ✨ It is not an Internet standard of any kind, and it's free to share with no limits on distribution 💅
Abstract
This document describes the requirements that let a service provider stretch pseudowires across multiple domains 🌈 Those domains can be autonomous systems under one provider's administrative control, IGP areas inside one autonomous system, different autonomous systems run by two or more service providers, or pseudowire domains that are set up administratively 🧚
Table of Contents
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Architecture ...............................................3
2. Terminology .....................................................6
2.1. Specification of Requirements ..............................6
3. Use Cases .......................................................7
3.1. Multi-Segment Pseudowire Setup Mechanisms ..................9
4. Multi-Segment Pseudowire Requirements ..........................10
4.1. All Mechanisms ............................................10
4.1.1. Architecture .......................................10
4.1.2. Resiliency .........................................11
4.1.3. Quality of Service .................................11
4.1.4. Congestion Control .................................12
4.1.5 Generic Requirements for MS-PW Setup Mechanisms ....13
4.1.6. Routing ............................................14
4.2. Statically Configured MS-PWs ..............................15
4.2.1. Architecture .......................................15
4.2.2. MPLS-PWs ...........................................15
4.2.3. Resiliency .........................................15
4.2.4. Quality of Service .................................16
4.3. Signaled PW Segments ......................................16
4.3.1. Architecture .......................................16
4.3.2. Resiliency .........................................16
4.3.3. Quality of Service .................................17
4.3.4. Routing ............................................17
4.3.5. Additional Requirements on Signaled MS-PW Setup
Mechanisms .........................................17
4.4. Signaled PW / Dynamic Route ...............................18
4.4.1. Architecture .......................................18
4.4.2. Resiliency .........................................18
4.4.3. Quality of Service .................................18
4.4.4. Routing ............................................18
5. Operations and Maintenance (OAM) ...............................19
6. Management of Multi-Segment Pseudowires ........................20
6.1. MIB Requirements ..........................................20
6.2. Management Interface Requirements .........................21
7. Security Considerations ........................................21
7.1. Inter-Provider MS-PWs .....................................21
7.1.1. Data-Plane Security Requirements ...................21
7.1.2. Control-Plane Security Requirements ................23
7.2. Intra-Provider MS-PWs .....................................25
8. Acknowledgments ................................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................251. Introduction ✨
1.1. Scope
okay so this document lays out the requirements for stretching pseudowires across more than one packet switched network (PSN) domain, and/or more than one PSN tunnel 🚀 These stretched pseudowires are called multi-segment pseudowires (MS-PWs) 💜 Requirements for single-segment pseudowires (SS-PWs), the ones that go edge to edge across just one PSN domain, live in [RFC3916] 🫶 This document is not meant to invalidate any part of [RFC3985], so nothing in [RFC3985] gets thrown out 🙈
This document adds extra requirements that apply to MS-PWs. Those requirements don't apply to PSNs that only support SS-PWs, so if your network is SS-PW only, you're off the hook 💅
1.2. Architecture
the next bit is all about the reference models that come from [RFC3985] and support PW emulated services. There are three figures, and they're giving architecture realness 😭
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
Native service Native service
Figure 1: PWE3 Reference Configurationso Figure 1 is the PWE3 reference architecture from [RFC3985] 🌸 It covers the case where a PSN tunnel runs between two edges of one PSN domain, carrying a PW whose endpoints sit at those edges 🦋
Native |<--------Multi-Segment Pseudowire----->| Native
Service | PSN PSN | Service
(AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
| V V 1 V V 2 V V |
| +-----+ +-----+ +---- + |
+---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+
| |---------|........PW1.......... |...PW3..........|---|----| |
|CE1| | | | | | | | | |CE2|
| |---------|........PW2...........|...PW4..........|--------| |
+---+ | | |==========| |==========| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| |
| |
|<------------------- Emulated Service ------------------->|
Figure 2: PW Switching Reference ModelFigure 2 takes that same setup and stretches it into a multi-segment case 🧚 Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) give PWE3 service to CE1 and CE2 ✨ Those PEs terminate different PSN tunnels, PSN Tunnel 1 and PSN Tunnel 2, and they might live in different PSN or pseudowire domains 🌈 One PSN tunnel runs from T-PE1 to S-PE1 across PSN1, and a second one runs from S-PE1 to T-PE2 across PSN2 💅
PWs connect the Attachment circuits (ACs) on T-PE1 to the matching ACs on T-PE2 🫶 At S-PE1, each PW on PSN tunnel 1 gets switched onto a PW in the tunnel across PSN2, and that completes the multi-segment PW (MS-PW) between T-PE1 and T-PE2 💖 That makes S-PE1 the PW switching point, and it's also called the PW switching provider edge (S-PE) 👑 PW1 and PW3 are segments of the same MS-PW, while PW2 and PW4 are segments of another pseudowire 🎀 PW segments of the same MS-PW (for example, PW1 and PW3) MAY be the same PW type or different types, and PSN tunnels (for example, PSN Tunnel 1 and PSN Tunnel 2) can be the same or different technology 🦋 This document requires support for MS-PWs with segments of the same PW type only, so that's the bar you need to hit 💅
An S-PE switches an MS-PW from one segment to the next based on the PW identifiers (for example, the PW label in the case of MPLS PWs) 🌸 In Figure 2, the domains that PSN Tunnel 1 and PSN Tunnel 2 cross could be IGP areas in the same IGP network, or just PWE3 domains in a single flat IGP network, for instance 🧚
|<------Multi-Segment Pseudowire------>|
| AS AS |
AC | |<----1---->| |<----2--->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| |=====| |=====| | | +----+
| |-------|.....PW1..........PW2.........PW3.....|-------| |
| CE1| | | | | | | | | | | |CE2 |
+----+ | | |=====| |=====| |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| T-PE1 S-PE2 S-PE3 T-PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<------------------- Emulated Service --------------->|
Figure 3: PW Switching Inter-Provider Reference ModelNow Figure 2 only shows a single S-PE, but a PW can pass through more than one S-PE on its path 💜 Figure 3 is the multi-AS case, where there's an S-PE (S-PE2) on the border of one AS (AS1) and another S-PE (S-PE3) on the border of the other AS (AS2) 🌈 An MS-PW that runs from the edge of one AS (T-PE1) to the edge of the other AS (T-PE4) is made of three segments: (1) PW1, a segment in AS1; (2) PW2, a segment between the two border routers (S-PE2 and S-PE3) that act as switching PEs; and (3) PWE3, a segment in AS2 ✨ AS1 and AS2 could belong to the same provider (for example, AS1 could be an access network or metro transport network, and AS2 could be an MPLS core network), or to two different providers (for example, AS1 for Provider 1 and AS2 for Provider 2) 🫶
part 1 of 6 is done, bestie! 🧚 more sections are coming, so stay tuned 💖
2. Terminology 💅
RFC 3985 [RFC3985] already gives us the PWE3 terminology, so bestie, we're only adding a few extra terms for multi-segment pseudowires. 🦋
- PW Terminating Provider Edge (T-PE). This is a PE where the customer-facing attachment circuits (ACs) get bound to a PW forwarder. A Terminating PE shows up in the first and last segments of an MS-PW. It's the PE from RFC 3985, just with extra functionality. 🎀
- Single-Segment Pseudowire (SS-PW). This is a PW set up directly between two PE devices. Each direction of an SS-PW goes through one PSN tunnel connecting the two PEs. 🌸
- Multi-Segment Pseudowire (MS-PW). This is a static or dynamically configured set of two or more contiguous PW segments that act and function like one single point-to-point PW. ✨ Each end of an MS-PW by definition MUST terminate on a T-PE. 👑
- PW Segment. This is a single-segment PW, or a part of a multi-segment PW, that gets set up between two PE devices (T-PEs and/or S-PEs). 🧚
- PW Switching Provider Edge (S-PE). This is a PE that can switch the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels carrying the preceding and succeeding segments of the MS-PW, so it's a PW switching point for that MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. 🙈 It also runs the protocols it needs to set up and manage PW segments with other PW switching points and terminating PEs. 💖
2.1. Specification of Requirements 🎀
Okay so, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way [RFC2119] describes. 📖 Hold onto that, it matters for everything below. 🔥
3. Use Cases 🌈
PWE3 already defines the signaling and encapsulation techniques for setting up SS-PWs between a pair of terminating PEs (T-PEs), and honestly? In the vast majority of cases, that's sufficient. 💅 MS-PWs may be useful in the following situations:
- i. Inter-Provider PWs: An Inter-Provider PW is a PW that stretches from a T-PE in one provider domain to a T-PE in another provider domain. 🦋
- ii. It may not be possible, desirable, or feasible to set up a direct PW control channel between T-PEs that live in different provider networks, just to set up and maintain PWs. 😭 At a minimum, a direct PW control channel setup (for example, a targeted LDP session) needs knowledge of and reachability to the remote T-PE IP address. The local T-PE may not have access to that info because of operational or security constraints. Also, an SS-PW would need a PSN tunnel to exist between the local T-PE and the remote T-PE. It may not be feasible or desirable to stretch single, contiguous PSN tunnels between T-PEs in one domain and T-PEs in another domain, for security and/or scalability reasons, or because the two domains might be using different PSN technologies. 🫶
- iii. MS-PW setup, maintenance, and forwarding procedures must satisfy requirements placed by the constraints of a multi-provider environment. 💜 An example is the inter-AS L2VPN scenario, where the T-PEs live in different provider networks (ASs), and it's current practice to MD5-key all control traffic exchanged between two networks. An MS-PW lets the providers confine MD5 key administration for the LDP session to just the PW switching points connecting the two domains. 🔐
- iv. PSN Interworking: PWE3 signaling protocols and PSN types may differ across provider networks. The terminating PEs may be connected to networks using different PW signaling and/or PSN protocols. In that case, it's not possible to use an SS-PW. 💀 An MS-PW with the right interworking done at the PW switching points can enable PW connectivity between the terminating PEs in this scenario. 🍓
- v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: There's a requirement to deploy PWs edge to edge in large service provider networks. These networks usually have hundreds or thousands of aggregation devices at the edge, and each one of them would be a PE. 👑 On top of that, these PWs need explicit bandwidth guarantees. To make that happen, the PWs will be tunneled over PSN TE-tunnels with bandwidth constraints. A single-segment pseudowire architecture would need a full mesh of PSN TE-tunnels provisioned so PWs can be set up between all PEs. 😩 Inter-provider PWs riding traffic engineered tunnels add even more tunnels that the PEs and the core network would have to support as the total number of PEs goes up. 🌸
In this environment, there's a requirement to either support a sparse mesh of PSN TE-tunnels and PW signaling adjacencies, or to partition the network into a bunch of smaller PWE3 domains. Either way, a PW would have to pass through more than one PSN tunnel hop along its path. ✨ The goal is to reduce the number of tunnels that must be supported, and with that, the complexity and scalability problems that may come up. 🧚
- vi. Pseudowires in access/metro networks: Service providers want to extend PW technology to access and metro networks to cut down on maintenance complexity and operational costs. 💖 Today's access and metro networks are legacy (Time Division Multiplexed (TDM), Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), or Frame Relay/Asynchronous Transfer Mode (ATM)), Ethernet, or IP based. 🌈
Because of these architectures, circuits (for example, Ethernet Virtual Circuits (EVCs), ATM VCs, TDM circuits) in the access/metro are traditionally handled as attachment circuits, in their native format, all the way to the edge of the IP-MPLS network where the PW starts. 😵💫 That combo means multiple separate access networks, and it makes end-to-end control, provisioning, and maintenance a whole mess. Also, when a TDM or SONET/SDH access network gets replaced with a packet-based infrastructure, expenses may go down because statistical multiplexing moves closer to the end user, and multiple services converge onto a single access network. 💅
Access networks have a number of properties that affect how PWs get applied. For example, there are access mechanisms where the PSN isn't of an IETF specified type, but uses mechanisms compatible with PWE3's at the PW layer. 🦋 Here, use case (iv) may apply. Plus, many networks consist of hundreds or thousands of access devices, so there's a desire to support a sparse mesh of PW signaling adjacencies and PSN tunnels. That means use case (v) may apply. Finally, access networks also tend to differ from core networks in that the access PW setup and maintenance mechanism may only be a subset of the one used in the core. 🙈
Using MS-PWs, access and metro network elements only need to maintain PW signaling adjacencies with the PEs they directly connect to. They don't need PW signaling adjacencies with every other access and metro network device. 🫶 The PEs in the PSN backbone, in turn, maintain PW signaling adjacencies among each other. A PSN tunnel also gets set up between an access element and the PE it connects to. Another PSN tunnel needs to be established between every PE pair in the PSN backbone. An MS-PW may be set up from one access network element to another access element with three segments: (1) access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN-PE to access element. In this MS-PW setup, access elements are T-PEs while PSN-PEs are S-PEs. 🧚 It should be noted that the PSN backbone can also be segmented into PWE3 domains, which results in more segments per PW. ⭐
3.1. Multi-Segment Pseudowire Setup Mechanisms 🔥
This requirements document assumes the above use cases get realized using one or more of the following mechanisms:
- i. Static Configuration: The switching points (S-PEs), in addition to the T-PEs, are manually provisioned for each segment. 🛠️
- ii. Pre-Determined Route: The PW is established along an administratively determined route, using an end-to-end signaling protocol with automated stitching at the S-PEs. 🗺️
- iii. Signaled Dynamic Route: The PW is established along a dynamically determined route, using an end-to-end signaling protocol with automated stitching at the S-PEs. The route is selected with the help of one or more dynamic routing protocols. 🧠
Just so we're on the same page: we define the PW route to be the set of S-PEs that an MS-PW passes through between a given pair of T-PEs. ✨ PSN tunnels along that route can be explicitly specified, or locally selected at the S-PEs and T-PEs. The routing of the PSN tunnels themselves is outside the scope of the requirements in this document. 🌸
4. Multi-Segment Pseudowire Requirements 👑
Here's where the details get real. The following sections spell out the requirements that the above use cases put on the MS-PW setup mechanisms. 💜
4.1. All Mechanisms 🦋
The following generic requirements apply to the three MS-PW setup mechanisms defined in the previous section. 🎀
4.1.1. Architecture 🏗️
- i. If MS-PWs are tunneled across a PSN that only supports SS-PWs, then only the requirements of [RFC3916] apply to that PSN. The fact that the overlay is carrying MS-PWs MUST be transparent to the routers in the PSN. 🫶
- ii. The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or a T-PE from the MS-PW architecture viewpoint. P-routers provide transparent PSN transport for PWs and MUST not have any knowledge of the PWs traversing them. 🙈
- iii. The MS-PWs MUST use the same encapsulation modes specified for SS-PWs. 💖
- iv. The MS-PWs MUST be composed of SS-PWs. 🧚
- v. An MS-PW MUST be able to pass across PSNs of all technologies supported by PWE3 for SS-PWs. When crossing from one PSN technology to another, an S-PE must provide the necessary PSN interworking functions in that case. 🌈
- vi. Both directions of a PW segment MUST terminate on the same S-PE/T-PE. ⭐
- vii. S-PEs MAY only support switching PWs of the same PW type. In this case, the PW type is transparent to the S-PE in the forwarding plane, except for functions needed to provide for interworking between different PSN technologies. 🍓
- viii. Solutions MAY provide a way to prioritize the setup and maintenance process among PWs. 💅✨
4.1.2. Resiliency ✨
okay bestie, let's talk about what happens when something on the path of an MS-PW dies 💀. Protection mechanisms MUST be provided for that, and what they look like depends on how the MS-PW was set up 🔥. These are the generic resiliency requirements that apply to every MS-PW setup mechanism 👑:
- i. Setting up a backup PW for a primary PW SHOULD be supported 🦋. Switching over from the primary PW to the backup PW when a failure gets detected SHOULD be provided too 💅.
- ii. Being able to configure an end-to-end backup PW path for a primary PW path SHOULD be supported 🎀. The primary and backup paths may be statically configured, statically specified for signaling, or dynamically selected via dynamic routing, depending on the MS-PW establishment mechanism 🌸. Backup and primary paths should be able to go through separate S-PEs ✨. The backup path MAY be signaled at configuration time or after failure 🧚.
- iii. A primary PW and a backup PW that use a different T-PE from the primary SHOULD be supported 💜.
- iv. Automatic mechanisms for a fast switchover from the primary PW to the backup PW when a failure is detected SHOULD be provided ⭐.
- v. A mechanism to automatically revert from the backup PW to the primary PW MAY be provided 🌈. When it is provided, it MUST be configurable 🫶.
4.1.3. Quality of Service
Pseudowires are meant to carry emulated services like TDM and ATM 🍓, and those can have strict QoS needs per connection 😭. That can mean absolute or relative guarantees on packet loss, delay, and jitter 💖. The guarantees come partly from reserving enough network resources (like bandwidth) and partly from giving each packet the right treatment (like scheduling priority and drop precedence) all the way through the network 🔥.
For SS-PWs, a traffic engineered PSN tunnel (that's MPLS-TE) can be used so the P-routers have enough resources reserved for the PWs riding on that tunnel ✨. In this case, T-PEs MUST have the ability to automatically request PSN tunnel resources in the direction of traffic 💅. That covers things like admission control of PWs onto the PSN tunnel and keeping track of reserved versus available bandwidth on the tunnel 📊. When the tunnel supports multiple classes of service (CoS), such as E-LSP, bandwidth management is required per CoS 🎀.
For MS-PWs, each S-PE maps a PW segment to a PSN tunnel 🦋. Solutions MUST let S-PEs and T-PEs automatically bind a PW segment to a PSN tunnel based on CoS and bandwidth requirements when those attributes are specified for a PW 🌸. Solutions SHOULD also offer binding a PW segment to a tunnel as a matter of policy configuration 🧚. S-PEs and T-PEs must be capable of automatically requesting PSN tunnel resources per CoS 💜.
S-PEs and T-PEs MUST be able to attach a CoS marking (for example, the EXP field value for MPLS PWs) to PW PDUs 🌈. That marking affects how the packet gets treated 👑. The marking depends on the PSN technology, so solutions must allow the necessary CoS mapping to be configured when an MS-PW crosses from one PSN technology to another 🔥. Different administrative domains might also use different CoS values to mean the same treatment 😭. Solutions MUST provide the ability to define CoS marking maps on S-PEs at administrative domain boundaries, so a CoS value can be translated as a PW PDU moves from one domain to the next 🫶.
[RFC3985] requires PWs to respond to path congestion by lowering their transmission rate 💀. The alternative is that RFC 3985 allows PWs without a congestion control mechanism to send using explicitly reserved capacity along a provisioned path 🌸. MS-PWs are a type of PW, so this requirement reaches them too ✨. Applied to MS-PWs, RFC 3985 means they need a congestion control mechanism that works across the whole MS path, or an explicit provisioning step that reserves enough capacity in every domain along the MS path before the MS-PW starts sending 🧚. So S-PEs are REQUIRED to reject attempts to set up MS-PW segments for PW types that either don't use an appropriate congestion control scheme, or when resources sufficient for the PW's transmission rate can't be reserved along the path 🚫💅.
4.1.4. Congestion Control
[RFC3985] requires all PWs to respond to congestion, so they conform to [RFC2914] 💖. Without a well-defined congestion control mechanism, [RFC3985] lets PWs travel across paths that have been provisioned so the traffic from those PWs has no harmful effect on other traffic sharing the path, even when things get congested 🎀. These requirements extend to the MS-PWs defined in this document 🦋.
Path provisioning is often done with QoS reservation protocols or network management protocols 🌈. For SS-PWs, which stay inside a single administrative domain, several existing protocols can handle that provisioning 🔥. MS-PWs, though, may cross network domains controlled by multiple entities 🌸. Provisioning QoS across those paths is way harder because it needs inter-domain interactions 😭. Still, those difficulties do NOT cancel the requirement to provision path capacity for MS-PW use 💅. Each domain MUST individually implement a method to control congestion ✨. That can be QoS reservation or some other congestion control method 🧚. MS-PWs MUST NOT transmit across unprovisioned, best effort, paths in the absence of other congestion control schemes, as required by [RFC3985] 🚫👑.
Solutions MUST let S-PEs and T-PEs on the path of an MS-PW tell the other S-PEs and T-PEs on that path when congestion happens 📢. Congestion can be indicated by queue length, packet loss rate, or bandwidth measurement (among others) crossing a threshold 📊. The action a T-PE takes when it hears about congestion on the path of one of its PWs could be re-routing the MS-PW to an alternative path, including an alternative T-PE if one is available 🦋. If a PE, or an S-PE, knows that a particular link or tunnel is congested, it MUST not set up any new MS-PW that uses that link or tunnel 💀. Some PW types, like TDM PWs, are more sensitive to congestion than others 🌷. The reaction to a congestion notification MAY vary per PW type 🌈.
4.1.5. Additional Generic Requirements for MS-PW Setup Mechanisms
The MS-PW setup mechanisms MUST accommodate the service provider's practices, especially around security, confidentiality of SP information, and traffic engineering 🔐. Security and confidentiality matter extra when MS-PWs are set up across autonomous systems in different administrative domains 👀. These are the generic requirements that apply to the three MS-PW setup mechanisms defined earlier 💜:
- i. The ability to statically select S-PEs and PSN tunnels on a PW path MUST be provided 🎯. Static selection of S-PEs is by definition a requirement for the static configuration and signaled/static route setup mechanisms 🧚. This lets providers force an MS-PW through specific S-PEs to enforce their security and administrative policies 🛡️.
- ii. Solutions SHOULD minimize the amount of configuration needed to set up an MS-PW ✨.
- iii. Solutions should support different PW setup mechanisms on the same T-PE, S-PE, and PSN network 🌸.
- iv. Solutions MUST allow T-PEs to simultaneously support SS-PW signaling mechanisms as specified in [RFC4447], as well as MS-PW signaling mechanisms 💅.
- v. Solutions MUST ensure that an MS-PW will be set up when a path that satisfies the PW constraints for bandwidth, CoS, and other possible attributes does exist in the network 🙌.
- vi. Solutions must clearly define the setup procedures for each mechanism, so an MS-PW setup on T-PEs can only be interpreted as successful when all PW segments are successfully set up 🎀.
- vii. Admission control to the PSN tunnel needs to be performed against available resources, when applicable 📊. This process MUST be performed at each PW segment comprising the MS-PW 🔁. PW admission control into a PSN tunnel MUST be configurable ⚙️.
- viii. If the PSN tunnel doesn't have the resources needed for the new PW, an attempt to signal a new PSN tunnel, or to increase the capacity of the existing one, MAY be made 🌱. If the expanded PSN tunnel fails to set up, the PW MUST fail to set up 💀.
- ix. The setup mechanisms must allow a PW segment to be set up between two directly connected S-PEs without a PSN tunnel existing 🔗. This lets a PW segment be set up between two (Autonomous System Border Routers (ASBRs) when the MS-PW crosses AS boundaries, with no need to configure and set up a PSN tunnel 🌉. In this case, admission control must be done, when enabled, on the link between the S-PEs 🧐.
4.1.6. Routing
An goal of MS-PWs is to support the following connectivity 🗺️:
- i. MS-PWs MUST be able to traverse multiple service provider administrative domains 🌍.
- ii. MS-PWs MUST be able to traverse multiple autonomous systems within the same administrative domain 🏢.
- iii. MS-PWs MUST be able to traverse multiple autonomous systems belonging to different administrative domains 🌐.
- iv. MS-PWs MUST be able to support any hybrid combination of the aforementioned connectivity scenarios, including both PW transit and termination in a domain 🦋.
4.2. Statically Configured MS-PWs
When the MS-PW segments are statically configured, the following requirements apply in addition to the generic requirements we just covered 🎀.
4.2.1. Architecture
There are no additional requirements on the architecture 🙌.
4.2.2. MPLS-PWs
Solutions should allow static configuration of MPLS labels for MPLS-PW segments, and cross-connecting those labels to the preceding and succeeding segments ✨. This is especially useful when an MS-PW crosses provider boundaries and two providers don't want to run any PW signaling protocol between them 🤝. A T-PE or S-PE that allows static labels for MS-PW segments should also simultaneously allow dynamic label assignments for other MS-PW segments 💜. It's worth noting that when two interconnected S-PEs don't have signaling peering for setting up MS-PW segments, they should have in-band PW Operations and Maintenance (OAM) capabilities that relay PW or attachment circuit defect notifications between the adjacent S-PEs 🔔🌈.
4.2.3. Resiliency 🛡️
okay so this is where we talk about backup plans 🫶 The solution should allow for protecting a single PW segment, a contiguous set of PW segments, or the whole end-to-end path. The primary and protection segments have to share the same segment endpoints, bestie 💅 Solutions should allow for backup paths to be set up before the failure or as a result of one. Which one happens is picked by configuration. When resources are limited and can't cover every PW, the PWs with higher setup priorities get preference over other PWs being set up and over the holding priorities of existing PWs. Main character energy for the high-priority ones 👑
Solutions should strive to minimize traffic loss between T-PEs. Obsessed with this goal 🙈
4.2.4. Quality of Service 💖
The CoS and bandwidth of the MS-PW must be configurable at T-PEs and S-PEs. Configurable at both the T-PEs and the S-PEs, so you get to tune it everywhere 🎀
4.3. Signaled PW Segments ✨
When the MS-PW segments are dynamically signaled, the following requirements apply in addition to the generic requirements previously defined. The signaled MS-PW segments can sit on the path of a statically configured MS-PW, a signaled/statically routed MS-PW, or a signaled/dynamically routed MS-PW. It's giving flexibility 🦋
There are four different mechanisms defined to set up SS-PWs:
- i. Static set up of the SS-PW (MPLS or L2TPv3 forwarding)
- ii. LDP using PWid Forwarding Equivalence Class (FEC) 128
- iii. LDP using the generalized PW FEC 129
- iv. L2TPv3
The MS-PW setup mechanism MUST be able to support PW segments signaled with any of the above protocols. Which combinations of SS-PW signaling protocols a specific implementation supports is outside the scope of this document, so that's a different conversation 🌸
For the signaled/statically routed and signaled/dynamically routed MS-PW setup mechanisms, the following requirements apply in addition to the generic requirements previously defined. 🧚
4.3.1. Architecture 🏛️
There are no additional requirements on the architecture. Easy one, we're chilling 😌
4.3.2. Resiliency 🛡️
Solutions should allow for signaling a protection path for a PW segment, a sequence of segments, or the end-to-end path. The protection and primary paths for the protected segment(s) share the same respective segment endpoints. When admission control is enabled, systems must be careful not to double count bandwidth allocation at merged points (e.g., tunnels). Like, don't double count, periodt 💅
Solutions should allow for backup paths to be set up before the failure or as a result of one. The choice is made by configuration at the endpoints of the protected path. When resources are limited and can't satisfy all PWs, the PWs with higher setup priorities should get preference over the setup priorities of other PWs being set up or the holding priorities of existing PWs. Procedures must allow for the primary and backup paths to be diverse, so they don't end up hanging out on the same route 🦋
4.3.3. Quality of Service 💜
When the T-PE tries to signal an MS-PW, the following capability is required:
- i. Signaling must be able to identify the CoS associated with an MS-PW.
- ii. Signaling must be able to carry the traffic parameters for an MS-PW per CoS. Traffic parameters should be based on existing INTSERV definitions and must be used for admission control when admission control is enabled.
- iii. The PW signaling MUST enable separate traffic parameter values to be specified for the forward and reverse directions of the PW. Forward and reverse can have different values, iykyk 🫶
- iv. PW traffic parameter representations MUST be the same for all types of MS-PWs. One consistent format across the board ✨
- v. The signaling protocol must be able to accommodate a method to prioritize PW setup and maintenance operations among PWs.
4.3.4. Routing 🗺️
See the requirements for "Resiliency" above. Go back up and check that section 🔁
4.3.5. Additional Requirements on Signaled MS-PW Setup Mechanisms 📋
The following are further requirements on signaled MS-PW setup mechanisms:
- i. The signaling procedures MUST be defined such that the setup of an MS-PW is considered successful if all segments of the MS-PW are successfully set up. All segments or it's not a win 🏆
- ii. The MS-PW path MUST have the ability to be dynamically set up between the T-PEs by provisioning only the T-PEs. Only the endpoints get provisioned, and the rest figures itself out 🧚
- iii. Dynamic MS-PW setup requires that a unique identifier be associated with a PW and be carried in the signaling message. That identifier must contain sufficient information to determine the path to the remote T-PE through intermediate S-PEs. The ID has to carry enough info to find the route, literally the map 🗺️
- iv. In a single-provider domain, it is natural to have the T-PE identified by one of its IP addresses. This may also apply when an MS-PW is set up across multiple domains operated by the same provider. However, some service providers have security and confidentiality policies that prevent them from advertising reachability to routers in their networks to other providers (reachability to an ASBR is an exception). Thus, procedures MUST be provided to allow dynamic set up of MS-PWs under these conditions. Privacy policies are real, so the procedures have to cover that too 🔒
4.4. Signaled PW / Dynamic Route 🌈
The following requirements apply, in addition to those in Sections 4.1 and 4.3, when both dynamic signaling and dynamic routing are used. Double the rules, double the fun 💅
4.4.1. Architecture 🏛️
There are no additional architectural requirements. Nothing extra here 🌸
4.4.2. Resiliency 🛡️
The PW routing function MUST support dynamic re-routing around failure points when segments are set up using the dynamic setup method. Failure? Reroute, no drama 🦋
4.4.3. Quality of Service 💖
There are no additional QoS requirements. Easy pass ✨
4.4.4. Routing 🗺️
The following are requirements associated with dynamic route selection for an MS-PW:
- i. Routing must enable S-PEs and T-PEs to discover S-PEs on the path to a destination T-PE.
- ii. The MS-PW routing function MUST have the ability to automatically select the S-PEs along the MS-PW path. Some of the S-PEs MAY be statically selected and carried in the signaling to constrain the route selection process. You can hand-pick a few if you want, but the rest gets auto-selected 🎀
- iii. The PW routing function MUST support re-routing around failures that occur between the statically configured segment endpoints. This may be done by choosing another PSN tunnel between the two segment endpoints or by setting up an alternative tunnel. Same energy as before: failure happens, we reroute 🔁
- iv. Routing protocols must be able to advertise reachability information of attachment circuit (AC) endpoints. This reachability information must be consistent with the AC identifiers carried in signaling. The info has to match the IDs in the signaling, no mismatches 🫶
5. Operations and Maintenance (OAM) 🔍
OAM mechanisms for the attachment circuits are defined in the specifications for PW emulated specific technologies (e.g., ITU-T I.610 [i610] for ATM). These mechanisms let us, among other things, detect, localize, and diagnose defects in the network. They also enable communication of PW defect states on the PW attachment circuit. Note that this document uses the term OAM as Operations and Management as per ITU-T I.610, so don't mix it up 🧐
The interworking of OAM mechanisms for SS-PWs between ACs and PWs is defined in [PWE3-OAM]. These enable defect states to be propagated across a PWE3 network following the failure and recovery from faults. The defect news travels across the network 📣
OAM mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs. In addition, it should be possible to support both segment and end-to-end OAM mechanisms for both defect notifications and connectivity verification, so defects can be localized in a multi-segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE to S-PE, or S-PE to S-PE. Every combo is valid 🌟
The following requirements apply to OAM for MS-PWs:
- i. Mechanisms for PW segment failure detection and notification to other segments of an MS-PW MUST be provided.
- ii. MS-PW OAM SHOULD be supported end-to-end across the network.
- iii. Single ended monitoring SHOULD be supported for both directions of the MS-PW.
- iv. SS-PW OAM mechanisms (e.g., [RFC5085]) SHOULD be extended to support MS-PWs on both an end-to-end basis and a segment basis.
- v. All PE routers along the MS-PW MUST agree on a common PW OAM mechanism to use for the MS-PW. Everyone on the path has to be on the same page 💜
- vi. At the S-PE, defects on a PSN tunnel MUST be propagated to all PWs that utilize that particular PSN tunnel. One tunnel problem, everybody hears about it 📢
- vii. The directionality of defect notifications MUST be maintained across the S-PE. Direction stays intact, no flipping 🙃
- viii. The S-PE SHOULD be able to behave as a segment endpoint for PW OAM mechanisms.
- ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages transparently. Pass it through, no peeking 🫣
- x. Performance OAM is required for both MS-PWs and SS-PWs to measure round-trip delay, one-way delay, jitter, and packet loss ratio. Measure all the things ⏱️
6. Management of Multi-Segment Pseudowires ⚙️
Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms for network operators to manage the emulated service. Management mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs, as defined in [RFC3916]. Same vibe as the SS-PW side, just bigger 🧚
It SHOULD also be possible to manage the additional attributes for MS-PWs. The operator that starts setting up an MS-PW may be in a different PSN domain from the S-PEs and one of the T-PEs along the path. For that reason, mechanisms for remote management of the MS-PW SHOULD be provided. Remote control, but make it secure 🌐
The following additional requirements apply:
6.1. MIB Requirements 🗂️
- i. MIB Tables MUST be designed to facilitate configuration and provisioning of the MS-PW at the S-PEs and T-PEs.
- ii. The MIB(s) MUST facilitate inter-PSN configuration and monitoring of the ACs.
6.2. Management Interface Requirements 🖥️
- i. Mechanisms MUST be provided to enable remote management of an MS-PW at an S-PE or T-PE. It SHOULD be possible for these mechanisms to operate across PSN domains. An example of a commonly available mechanism is the command line interface (CLI) over a telnet session. Telnet CLI is the classic example 💀
- ii. For security or other reasons, it SHOULD be possible to disable the remote management of an MS-PW. Off switch, always good to have 🙈
7. Security Considerations 🔐
This document specifies the requirements both for MS-PWs that can be set up across domain boundaries administered by one or more service providers (inter-provider MS-PWs), and for MS-PWs that are only set up across one provider (intra-provider MS-PWs). Security is the whole vibe here, so we take it seriously 😭
7.1. Inter-Provider MS-PWs 🌉
The security requirements for MS-PW setup across domains administered by one service provider are the same as those described under security considerations in [RFC4447] and [RFC3916]. These requirements also apply to inter-provider MS-PWs. Same rules carry over, no exceptions 🔒
In addition, [RFC4111] identifies user and provider requirements for L2 VPNs that apply to MS-PWs described in this document. In this section, the focus is on the additional security requirements for inter-provider operation of MS-PWs in both the control plane and data plane. Some of these requirements may overlap with those in [RFC4111], so expect a little déjà vu ✨
7.1.1. Data-Plane Security Requirements 🛡️✨
okay so bestie, "security in the data plane" just means protection against two things 👀
-i.Packets from inside an MS-PW ending up at a PE or an AC that the PW was never meant to connect to, unless it's done in a way that matches the MS-PW's policies. 🙅♀️-ii.Packets from outside an MS-PW sneaking into it, unless that also matches the MS-PW's policies. 🚫
MS-PWs that cross service provider (SP) domain boundaries can connect one T-PE in one SP domain to a T-PE in another provider domain 🌍 They can also transit other provider domains, even when both T-PEs belong to the same SP 🦋 In these cases, one or more PDUs could get falsely inserted into an MS-PW at the originating, terminating, or transit domain. 😱 That kind of false injection can come from a malicious attack or from a fault in the S-PE. 💀 Solutions MAY provide mechanisms for ensuring the end-to-end authenticity of MS-PW PDUs. 🔐
The data plane security requirements at a service provider border for MS-PWs are basically a cousin of the ones for inter-provider BGP/MPLS IP Virtual Private Networks [RFC4364] 💅 Specifically, an S-PE or T-PE SHOULD discard a packet received from a particular neighbor over the service provider border, unless one of these two conditions holds:
-i.Any MPLS label processed at the receiving S-PE or T-PE, such the PSN tunnel label or the PW label, has a label value that the receiving system has distributed to that neighbor; or-ii.Any MPLS label processed at the receiving S-PE or T-PE, such as the PSN tunnel label or the PW label, has a label value that the receiving S-PE or T-PE has previously distributed to the peer S-PE or T-PE beyond that neighbor (i.e., when it is known that the path from the system to which the label was distributed to the receiving system is via that neighbor). 🧩
One of the domains crossed by an MS-PW may decide to selectively mirror the PDUs of an MS-PW for eavesdropping purposes 👀 It may also decide to selectively hijack the PDUs of an MS-PW by directing them away from their destination 😭 Either way, the privacy of an MS-PW can be violated. 💔
Some types of PWs make assumptions about the security of the underlying PSN. The minimal security provided by an MPLS PSN might not be sufficient to meet the security requirements expected by the applications using the MS-PW 🙈 This document does not place any requirements on protecting the privacy of an MS-PW PDU via encryption. However, encryption may be required at a higher layer in the protocol stack, based on the application or network requirements. 🔒
The data plane of an S-PE at a domain boundary MUST be able to police incoming MS-PW traffic to the MS-PW traffic parameters or to an administratively configured profile 🚨 The option to enable/disable policing MUST be provided to the network administrator. This is so an MS-PW, or a group of MS-PWs, doesn't grab more resources than it was allocated 🍓 On top of that, the data plane of an S-PE MUST be able to police OAM messages to a pre-configured traffic profile, or to filter out these messages upon administrative configuration. 🧚
An ingress S-PE MUST ensure that an MS-PW receives the CoS treatment configured or signaled for that MS-PW at the S-PE 👑 Specifically, an S-PE MUST guard against packets marked in the exp bits or IP-header Differentiated Services (DS) field (depending on the PSN) for a better CoS than they should receive. 🛑
An ingress S-PE MUST be able to define per-interface or interface-group label space for MPLS-PWs (a group may correspond to interfaces to a peer-provider) 🎀 An S-PE MUST be configurable not to accept labeled packets from another provider unless the bottom label is a PW-label assigned by the S-PE on the interface on which the packet arrived. 🙅♀️
Data plane security considerations for SS-PWs specified in [RFC3985] also apply to MS-PWs. 📚
7.1.2. Control-Plane Security Requirements 🎀🔐
An MS-PW connects two attachment circuits. It is important to make sure PW connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit 😳 The fault in the connection can start at a remote T-PE or an S-PE. 🙃
Where a PW segment crosses a border between one provider and another provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs interconnecting the two providers 🌉 Directly interconnecting the S-PEs using a physically secure link, and enabling signaling and routing authentication between the S-PEs, eliminates the possibility of receiving an MS-PW signaling message or packet from an untrusted peer 🫶 Other configurations are possible. For example, P routers for the PSN tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In which case, the S-PEs/T-PEs MUST satisfy themselves of the security and privacy of the path 🧐
The configuration and maintenance protocol MUST provide a strong authentication and control protocol data protection mechanism 💪 This option MUST be implemented, but it should be deployed according to the specific PSN environment requirements. Furthermore, authentication using a signature for each individual MS-PW setup message MUST be available, in addition to an overall control protocol session authentication and message validation. ✍️
Since S-PEs in different provider networks SHOULD reside at each end of a physically secure link, or be interconnected by a limited number of trusted PSN tunnels, each S-PE will have a trust relationship with only a limited number of S-PEs in other ASs 🥰 Thus, it is expected that current security mechanisms based on manual key management will be sufficient. If deployment situations arise that require large scale connection to S-PEs in other ASs, then a mechanism based on RFC 4107 [RFC4107] MUST be developed. 🗝️
Peer authentication protects against IP address spoofing, but it does not prevent one peer (S-PE or T-PE) from connecting to the wrong attachment circuit 🙈 Under a single administrative authority, this may be the result of a misconfiguration. When the MS-PW crosses multiple provider domains, this may be the result of a malicious act by a service provider or a security hole in that provider network 😤 Static manual configuration of MS-PWs at S-PEs and T-PEs provides a greater degree of security. If an identification of both ends of an MS-PW is configured and carried in the signaling message, an S-PE can verify the signaling message against the configuration ✅ To support dynamic signaling of MS-PWs, where only endpoints are provisioned and S-PEs are dynamically discovered, mechanisms SHOULD be provided to configure such information on a server and to use that information during a connection attempt for validation. 🖥️
An incoming MS-PW request/reply MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer 🚷 An eligible peer is an S-PE or a T-PE with which the originating S-PE or T-PE has a trust relationship. The number of such trusted T-PEs or S-PEs is bounded and not anticipated to create a scaling issue for the control plane authentication mechanisms. 📈
If a peering adjacency has to be established prior to exchanging setup requests/responses, peering MUST only be done with eligible peers 🤝 The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations) or automatically generated from the local PW configuration information. 📝
Furthermore, the restriction of peering sessions to specific interfaces MUST also be provided. The S-PE and T-PE MUST drop the unaccepted signaling messages in the data path to avoid a Denial-of-Service (DoS) attack on the control plane 🛡️
Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. Thus, means of preventing source address spoofing must be in place 🕵️♀️ For example, if eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing. 🧱
S-PEs that connect one provider domain to another provider domain MUST have the capability to rate-limit signaling traffic in order to prevent DoS attacks on the control plane 🚦 Furthermore, detection and disposition of malformed packets, and defense against various forms of attacks that can be protocol-specific, MUST be provided. 🙌
7.2. Intra-Provider MS-PWs 🏠
Security requirements for pseudowires are provided in [RFC3916]. These requirements also apply to MS-PWs. 📖
MS-PWs are intended to enable many more PEs to provide PWE3 services in a given service provider network than traditional SS-PWs 🌸 This is especially true in access and metro environments, where the PE may be situated closer to the ultimate endpoint of the service. In order to limit the impact of a compromise of one T-PE in a service provider network, the data path security requirements for inter-provider MS-PWs also apply to intra-provider MS-PWs in such cases. 🫧
8. Acknowledgments 🫶
The editors gratefully acknowledge the following contributors: Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel-Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), David McDysan (Verizon), Rahul Aggarwal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE), and Stewart Bryant (Cisco). 💜
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
- [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
9.2. Informative References
- [i610] Recommendation I.610 "B-ISDN operation and maintenance principles and functions", February 1999.
- [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [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.
- [RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
- [PWE3-OAM] Nadeau, T., Ed., Morrow, M., Ed., Busschbach, P., Ed., Alissaoui, M.,Ed., D. Allen, Ed., "Pseudo Wire (PW) OAM Message Mapping", Work in Progress, March 2005.
- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
Authors' Addresses ✨
okay bestie, here are the three humans who wrote this thing 🫶
Nabil Bitar
Verizon
117 West Street
Waltham, MA 02145
EMail: nabil.n.bitar@verizon.comMatthew Bocci
Alcatel-Lucent Telecom Ltd,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
EMail: matthew.bocci@alcatel-lucent.co.ukLuca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.comFull Copyright Statement 🎀
the legal bit, but make it cute 💅
Copyright (C) The IETF Trust (2008) 📅 ✨
this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🔒 so don't just copy-paste their homework, lol 💀
the document and the info in it are given to you on an "AS IS" basis, and the people involved are not making promises about it. here's the official all-caps disclaimer, verbatim, because legal said so 🙈
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
the IETF is not picking a side on whether any patents or other IP rights apply to the tech in this doc, or whether you could get a license to use them. it also hasn't gone hunting for any of that stuff 🕵️♀️ info about how RFC docs handle rights lives in BCP 78 and BCP 79.
if you want to see IPR disclosures that were sent to the IETF Secretariat, or any promises to license the tech, check the IETF's online IPR repository at http://www.ietf.org/ipr. that's also where you'd find out if someone tried to get a general license or permission for implementers or users of this spec 👑
and if you know of any copyrights, patents, patent applications, or other proprietary rights that might cover tech that may be required to implement this standard, tell the IETF about it at ietf-ipr@ietf.org 🫶 the IETF really appreciates the heads-up, periodt ✨
📦 where this page comes from
- ietf: rfc5254 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms