RFC 5586
MPLS Generic Associated Channel
MPLS Generic Associated Channel 🦋
Okay bestie, this one is from the Network Working Group and it's the RFC number 5586 🎀. It was written in June 2009 and it's a Standards Track doc, so it's the real deal. The editors are M. Bocci, M. Vigoureux, and S. Bryant. Bocci and Vigoureux are from Alcatel-Lucent, and Bryant is from Cisco Systems 💅. It updates RFC 3032, RFC 4385, and RFC 5085 ✨. It is not listed as obsoleting anything.
Status of This Memo
This doc specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ©️.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they're in effect on the date of publication. Please read these carefully, bestie, because they describe your rights and restrictions for this document 📜. You can find them at http://trustee.ietf.org/license-info.
Abstract
This doc generalizes how the pseudowire (PW) Associated Channel Header (ACH) can be used 🌸. That means it lets you build a control channel tied to MPLS Label Switched Paths (LSPs) and MPLS Sections, not just MPLS pseudowires. To spot the ACH sitting in the label stack, the doc also picks one of the reserved MPLS label values for the Generic Associated Channel Label (GAL). The GAL is used as a label-based exception mechanism, and it's giving main character energy ✨.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language and Terminology . . . . . . . . . . 5
2. Generic Associated Channel Header . . . . . . . . . . . . . . 5
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6
3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay so there's a real need for Operations, Administration, and Maintenance (OAM) mechanisms 🔥. These are the tools for fault detection, diagnostics, maintenance, and other stuff on a pseudowire (PW) and a Label Switched Path (LSP). The functions can run between any two Label Edge Routers (LERs)/Label Switching Router (LSRs), or Terminating Provider Edge routers (T-PEs)/Switching Provider Edge routers (S-PEs), along the path of an LSP or PW, respectively [MPLS-TP]. Some of these jobs can already be done with existing tools like Virtual Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (BFD-MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV]. BUT, a requirement has been flagged to level up this set of maintenance functions 💀, especially when MPLS networks are carrying packet transport services and transport network operations [OAM-REQ]. Examples include performance monitoring, automatic protection switching, and support for management and signaling communication channels 🧚.
Here's the big rule: these tools MUST be applicable to, and function in essentially the same manner (from an operational point of view) on MPLS PWs, MPLS LSPs, and MPLS Sections. They MUST also operate in-band on the PW or LSP, so they don't depend on Packet Switched Network (PSN) routing or on user traffic. They MUST NOT depend on dynamic control plane functions 🙅♀️.
VCCV [RFC5085] can use an Associated Channel Header (ACH) to give a PW an associated control channel between the PW's endpoints 🦋. OAM and other control messages get exchanged over that channel. This doc generalizes how the ACH applies, so the same associated control channel mechanism works for Sections, LSPs, and PWs. The generalized channel is known as the Generic Associated Channel (G-ACh). The ACH, specified in RFC 4385 [RFC4385], can be used with extra code points to support more MPLS maintenance functions on the G-ACh 🌈.
Generalizing the ACH to LSPs and Sections also needs a way to tell that a packet has an ACH followed by a non-service payload 🤔. So this doc defines a label-based exception mechanism. It tells an LSR (or LER) that a packet it receives on an LSP or Section belongs to an associated control channel. The label for this job is one of the MPLS reserved labels, and it's called the GAL (G-ACh Label). The GAL mechanism is designed to work together with the ACH for LSPs and MPLS Sections 🫶.
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that let an MPLS LSR spot and process MPLS OAM packets when they're encapsulated in an IP header 👀. These alerts are based on things like Time To Live (TTL) expiration, and/or on using an IP destination address in the range of 127.0.0.0/8 for IPv4, or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. These are the default ways to identify MPLS OAM packets when they're wrapped in an IP header. But sometimes these mechanisms just can't be used in some MPLS applications, e.g., MPLS Transport Profile (MPLS-TP) [MPLS-TP], especially when IP-based demultiplexing isn't an option 😭. So this doc defines a mechanism that is RECOMMENDED for identifying and encapsulating MPLS OAM and other maintenance messages when IP-based mechanisms, like the ones used in [RFC4379] and [BFD-MPLS], aren't available 🍓. Yet, this mechanism MAY be used in addition to the IP-based mechanisms too.
Note that in this doc, "maintenance functions" and "packets" are meant to be read in the broad sense 📚. That means a whole set of maintenance and management mechanisms, including OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages.
Also, the GAL and ACH apply to MPLS and PWs in general 💜. This doc specifies the general mechanism and uses MPLS-TP as an example application. Applying the GAL and ACH to other specific MPLS uses is outside the scope of this doc, so don't go there yet 🙅♀️.
1.1. Objectives
This doc defines a mechanism that solves the extended maintenance needs of emerging MPLS applications 🎀. It creates a generic control channel mechanism that can be applied to MPLS LSPs and Sections, while staying compatible with the PW associated channel. It also normalizes how the ACH gets used for PWs in a transport context. And it defines a label-based exception mechanism to alert LERs/LSRs that an ACH is present after the bottom of the label stack 🧚♀️.
1.2. Scope
This doc defines the encapsulation header for Section, LSP, and PW associated control channel messages 💅.
It does NOT define how associated control channel capabilities get signaled or negotiated between LERs/LSRs or between PEs. It also does NOT define how the various OAM functions operate 🙃.
It does NOT deprecate existing MPLS and PW OAM mechanisms, so they're all still good 🫶.
1.3. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119] 📖.
This doc also uses some extra terminology:
- ACH: Associated Channel Header
- G-ACh: Generic Associated Channel
- GAL: G-ACh Label
- G-ACh packet: Any packet containing a message that belongs to a protocol carried on a PW, LSP, or MPLS Section associated control channel. Examples include maintenance protocols such as OAM functions, signaling communications, or management communications 💖.
The terms "Section" and "Concatenated Segment" are defined in [TP-REQ] as follows. Note that the terms "Section" and "Section Layer Network" are synonymous 🌸:
- Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that transfers section layer client information between adjacent nodes in the transport path layer or transport service layer. Note that G.805 [G805] defines the section layer as one of the two layer networks in a transmission media layer network. The other layer network is the physical media layer network 🛤️.
- Concatenated Segment: A serial-compound link connection as defined in [G805]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence 🔗.
2. Generic Associated Channel Header
Okay, so VCCV [RFC5085] defines three Control Channel (CC) Types that can be used to swap OAM messages through a PW 🦋. CC Type 1 uses an ACH, and it's called "In-band VCCV". CC Type 2 uses the MPLS Router Alert Label to flag VCCV packets, and it's called "Out-of-Band VCCV". CC Type 3 uses the TTL to force the packet to be processed by the targeted router control plane, and it's called "MPLS PW Label with TTL == 1" ✨.
2.1. Definition ✨
okay so the ACH used to be only for PWs (pseudowires) 💅, and now it's getting a glow-up so it works for LSPs and Sections too 🦋. one thing to know: for PWs, the PWE3 control word [RFC4385] MUST be present in the encapsulation of user packets when the ACH is used to realize the associated control channel 🎀.
this is the ACH that CC Type 1 uses 🫶:
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 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Associated Channel Header
so in that figure, the first nibble is set to 0001b, which means it's a control channel tied to a PW, LSP, or Section 🌸. the Version field is set to 0, as specified in RFC 4385 [RFC4385] 💖. bits 8 to 15 are reserved and MUST be set to 0 and ignored on reception, so no drama there 🙈. bits 16 to 31 encode the possible Channel Types, and that 16-bit field is in network byte order ⭐.
ngl there's a side quest here 🧚. VCCV [RFC5085] already has ways to negotiate the Control Channel and Connectivity Verification (OAM function) Types between PEs. it's anticipated that similar mechanisms will be applied to LSPs, but that application will require further specification, and that specification is beyond the scope of this document 🍓.
the G-ACh MUST NOT be used to transport user traffic. this one's a hard no 💀
2.2. Allocation of Channel Types 🌈
the Channel Type field tells you what kind of message is riding on the associated control channel 👑. like, IPv4 or IPv6 if IP demultiplexing is used for those messages, or OAM or some other maintenance function if IP demux isn't used. when IP isn't the multiplexer, the Channel Type tells you the exact protocol carried in the associated control channel 💜.
the Channel Type values VCCV is using right now are defined elsewhere, like in RFC 4446 [RFC4446] and RFC 4385 [RFC4385] 🦋. extra Channel Type values and their maintenance functionality will be defined in other documents ✨. every document that specifies a protocol solution relying on the ACH MUST also specify the applicable Channel Type field value 🔥.
these values come from the PW Associated Channel Type registry [RFC4446], but this document tweaks the existing policy to allow a bit of experimentation 🧪. see Section 10 for the details 💅.
3. ACH TLVs 🎀
in some applications of the generalized associated control channel, you need one or more ACH TLVs to add extra context to the G-ACh packet 🫶. one use might be identifying the source and/or intended destination of the associated channel message. but it's not limited to addressing info, and it isn't restricted to transport network applications either 🌸.
if the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type 📝. if the ACH Channel Type definition does say that one or more ACH TLVs MAY precede the G-ACh message, then an ACH TLV Header MUST follow the ACH 💖. if no ACH TLVs are needed in a specific packet, but the Channel Type says ACH TLVs MAY be used, an ACH TLV Header MUST still be present, with its length field set to zero to show that no ACH TLVs follow 🙈.
if an ACH Channel Type specification does not explicitly say ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. no sneaking it in 💀
3.1. ACH TLV Payload Structure ✨
this section defines the structure of an ACH payload when an ACH TLV Header is present 🦋.
here's Figure 2, which shows the structure of a G-ACh packet payload 🧚:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: G-ACh Packet Payload
3.2. ACH TLV Header 💜
the ACH TLV Header tells you how long the set of ACH TLVs that follow it is 📏.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: ACH TLV Header
the Length field gives the length in octets of the complete set of TLVs, including any sub-TLVs, that follow the ACH TLV Header 🌷. a length of zero means no ACH TLVs follow this header. also, no padding is needed for the set of ACH TLVs 🫧.
the Reserved field is for future use, so it MUST be set to zero on transmission and ignored on reception 🔒.
3.3. ACH TLV Object 🍓
ACH TLVs MAY follow an ACH TLV Header 🎀. this section is where their structure gets defined and described 🧚.
each ACH TLV has a 16-bit Type field, then a 16-bit Length field that counts the octets in the Value field, which comes right after the Length field 💖. that 32-bit word is followed by zero or more octets of Value information. the format and semantics of the Value information are defined by the TLV Type as recorded in the TLV Type registry 📚. see Section 10 for more on that 🦋. note that the Value field of ACH TLVs MAY contain sub-TLVs 🌈. and once again, no padding is needed for individual TLVs or sub-TLVs ✨.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: ACH TLV Format
4. Generalized Exception Mechanism 🚨
generalizing the associated control channel mechanism to LSPs and Sections also needs a way to tell when a packet has an ACH followed by a non-service payload 🕵️♀️. this document says a label does that job, and it calls this special label the G-ACh Label (GAL) 🏷️. one of the reserved label values from RFC 3032 [RFC3032] is assigned for this purpose, and IANA assigned the value 13 to the GAL 🎉.
the GAL works as an alert-based exception mechanism that lets you:
- differentiate specific packets (i.e., G-ACh packets) from others, such as user-plane ones 👀
- indicate that the ACH appears immediately after the bottom of the label stack 📍
the GAL MUST only be used where both these purposes apply. no using it for fun 🙅♀️
4.1. Relationship with Existing MPLS OAM Alert Mechanisms 🦋
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that let an MPLS LSR spot and process MPLS OAM packets when they're encapsulated in an IP header 🔍. these alert mechanisms are based on things like Time To Live (TTL) expiration and/or using an IP destination address in the range of 127.0.0.0/8 or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively 🌐.
these are the default mechanisms for identifying MPLS OAM packets when they're encapsulated in an IP header, although the mechanism defined in this document MAY also be used 🫶.
4.2. GAL Applicability and Usage 💅
in MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs 🚫. it MUST always be at the bottom of the label stack (i.e., S bit set to 1) 📌. in other MPLS environments, though, this document places no restrictions on where the GAL may appear within the label stack or on its use with PWs 🌈. where the GAL is at the bottom of the label stack (i.e., S bit set to 1), it MUST always be followed by an ACH 🧚.
the GAL MUST NOT appear in the label stack when transporting normal user-plane packets 🙅♀️. also, when present, the GAL MUST NOT appear more than once in the label stack 💀.
a receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to another node based on the GAL label 🛑.
4.2.1. GAL Processing 🎀
the Traffic Class (TC) field (formerly known as the EXP field) of the Label Stack Entry (LSE) containing the GAL follows the definition and processing rules specified and referenced in [RFC5462] 💜.
the Time-To-Live (TTL) field of the LSE that contains the GAL follows the definition and processing rules specified in [RFC3443] ⭐.
4.2.1.1. MPLS Label Switched Paths and Segments ✨
okay so let's talk LSPs 🛤️ Figure 5</pict> shows two LERs (A and D) and two LSRs (B and C) for one LSP that's set up from A to D and gets switched through B and C. main character setup, honestly 💅
+---+ +---+ +---+ +---+
| A |-------------| B |-------------| C |-------------| D |
+---+ +---+ +---+ +---+Figure 5: Maintenance over an LSP
so in this example, a G-ACh lives on the LSP that runs between LERs A and D, going through LSRs B and C. only A and D may start new G-ACh packets. A, B, C, and D can all process and respond to G-ACh packets 🫶
Figure 6 is the packet format of an MPLS-TP G-ACh packet when it's used for an LSP 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: G-ACh Packet Format for an LSP
also, the LSP might get tunneled inside another LSP (say there's an MPLS Tunnel between B and C), so other LSEs may show up in the label stack too 🌈
so when the LER (A) wants to send a G-ACh message on the LSP's associated control channel, it generates the G-ACh message. it MAY prepend an ACH TLV Header and appropriate ACH TLVs 🎀 then it adds an ACH, pushes a GAL LSE onto that, and finally the LSP Label LSE goes on top of the whole packet ✨
- The TTL field of the GAL LSE MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules. ⏱️
- The S bit of the GAL MUST be set according to its position in the label stack (see Section 4.2). 🧚
- The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules. 🍓
LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards the targeted destination 🙅♀️
Note: This is because once a G-ACh packet has been sent on an LSP, no node has visibility of it unless the LSP label TTL expires or the GAL is exposed when the LSP label is popped. If this is at the targeted destination, for example, indicated by an address in an ACH TLV, then processing can proceed as specified below. If this is not the targeted destination, but the node has agreed to process packets on that ACH channel, then the processing applied to the packet is out of scope of this document. 💜
ok so when the labeled packet shows up, the targeted destination checks both the LSP Label and GAL LSE fields first, and then it SHOULD pass the whole packet to the appropriate processing entity 💖
4.2.1.2. MPLS Section
next up, Figure 7 shows an example of an MPLS Section 🌸
+---+ +---+
| A |-------------| Z |
+---+ +---+Figure 7: Maintenance over an MPLS Section
so for the MPLS Section, a G-ACh exists between A and Z. only A and Z can insert, extract, or process packets on this G-ACh 🔐
Figure 8 is the format of a G-ACh packet when it's used for an MPLS Section 🦋 here's the lowkey cool part: the GAL MAY provide the exception mechanism for a control channel in its own right, without being tied to a specific LSP. that gives you maintenance-related chat across one specific link between two LSRs. in this case, the GAL is the only label in the stack 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: G-ACh Packet Format for an MPLS Section
so when the head-end LSR (A) of the Section wants to send a G-ACh message on a control channel tied to the Section, it generates the G-ACh message. it MAY prepend an ACH TLV Header and appropriate ACH TLVs 🎀 next, the LSR adds an ACH. finally, it pushes a GAL LSE 🫶
- The TTL field of the GAL MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules. ⏱️
- The S bit of the GAL MUST be set according to its position in the label stack. (see Section 4.2). 🧚
- The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules. 🍓
intermediate nodes of the MPLS Section MUST NOT modify the G-ACh message, the ACH and the GAL towards the tail-end LSR (Z) 🙅♀️ and when the G-ACh packet shows up, the tail-end LSR (Z) checks the GAL LSE fields and then SHOULD pass the whole packet to the appropriate processing entity 💅
4.3. Relationship with RFC 3429
okay, so RFC 3429 [RFC3429] is about assigning one of the reserved label values, defined in RFC 3032 [RFC3032], to the "OAM Alert Label". user-plane MPLS OAM functions use that label to spot MPLS OAM packets. the value 14 is what they use 🔥
both this document and RFC 3429 [RFC3429] assign reserved label values for similar stuff, which is giving déjà vu energy 👀 the reasoning for a new reserved label goes like this:
- Unlike the mechanisms described and referenced in RFC 3429 [RFC3429], G-ACh messages will not reside immediately after the GAL but instead behind the ACH, which itself resides after the bottom of the label stack. 🌸
- The set of maintenance functions potentially operated in the context of the G-ACh is wider than the set of OAM functions referenced in RFC 3429 [RFC3429]. 🌈
- It has been reported that there are existing implementations and running deployments using the "OAM Alert Label" as described in RFC 3429 [RFC3429]. It is therefore not possible to modify the "OAM Alert Label" allocation, purpose, or usage. Nevertheless, it is RECOMMENDED that no further OAM extensions based on "OAM Alert Label" (Label 14) usage be specified or developed. 🙈
5. Compatibility ✨
procedures for handling a packet that arrives with an invalid incoming label are specified in RFC 3031 [RFC3031] 📜
An LER, LSR, or PE MUST discard received associated channel packets on which all of the MPLS or PW labels have been popped if any one of the following conditions is true:
- It is not capable of processing packets on the Channel Type indicated by the ACH of the received packet. 💀
- It has not, through means outside the scope of this document, indicated to the sending LSR, LER, or PE that it will process associated channel packets on the Channel Type indicated by the ACH of the received packet. 🙅♀️
- The packet is received on an Experimental Channel Type that is locally disabled. 🧪
- If the ACH was indicated by the presence of a GAL, and the first nibble of the ACH of the received packet is not
0001b. 🔢 - The ACH version is not recognized. 🫠
in addition, the LER, LSR, or PE MAY increment an error counter and MAY also issue a system and/or Simple Network Management Protocol (SNMP) notification 🔔
6. Congestion Considerations 🌊
the congestion considerations detailed in RFC 5085 [RFC5085] apply 💜
7. Major Contributing Authors 🎀
the editors would like to thank George Swallow, David Ward, and Rahul Aggarwal, who made a major contribution to the development of this document 🫶
George Swallow
Cisco Systems
Email: swallow@cisco.com
David Ward
Cisco Systems
Email: dward@cisco.com
Rahul Aggarwal
Juniper Networks
Email: rahul@juniper.net8. Acknowledgments 🌸
the editors gratefully acknowledge the contributions of Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau, and Siva Sivabalan 👑
the authors would also like to thank Malcolm Betts, ITU-T Study Group 15, and all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Team in ITU-T) involved in the definition and specification of the MPLS Transport Profile 🌈
9. Security Considerations 🔒
the security considerations for the associated control channel are described in RFC 4385 [RFC4385]. Further security considerations MUST be described in the relevant associated channel type specification. this part is not a drill, bestie 💀
RFC 5085 [RFC5085] provides data plane related security considerations. These also apply to a G-ACh, whether the alert mechanism uses a GAL or only an ACH 🛡️
10. IANA Considerations 🎀
Okay bestie, IANA put label value 13 aside for the GAL, pulling it from the reserved pool in the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry. 🦋
Channel Types for the Associated Channel Header come from the IANA "PW Associated Channel Type" registry [RFC4446]. That registry is currently handed out through IETF consensus, which the RFC 5226 folks call "IETF Review" [RFC5226]. The PWE3 working group picked this on purpose. The consensus was that pseudowire associated channel mechanisms should get reviewed by the IETF, and only the ones that fit the PWE3 architecture and requirements should get a code point. 💅
Here's the twist. A requirement showed up (see [OAM-REQ]) saying people need to be able to experiment with optimizations or extensions to OAM and other control protocols running in an associated channel, without going through the whole IETF standards process. The fix is experimental code points. That keeps experimental functions from eating code points in the IETF-allocated range, so the installed base of equipment is protected from accidental code point collisions. 🛡️ To make this work, IANA changed the code point allocation scheme for the PW Associated Channel Type like this:
0 - 32751 : IETF Review
32760 - 32767 : ExperimentalExperimental code points MUST be used according to the guidelines of RFC 3692 [RFC3692]. Experimental G-ACh functions MUST be disabled by default. The Channel Type value for any experimental OAM function MUST be configurable, and care MUST be taken so that OAM functions that can't interoperate are set up with different Channel Type values. 🚨 This is the part where you don't want to get sloppy, periodt.
The PW Associated Channel Type registry also got a new column that says whether the ACH is followed by an ACH TLV header (Yes/No). Right now there are two ACH Channel Type code points assigned, and neither one uses an ACH TLV header. So the new registry format looks like this 👇
Registry:
Value Description TLV Follows Reference
----- ---------------------------- ----------- ---------
0x21 ACH carries an IPv4 packet No [RFC4385]
0x57 ACH carries an IPv6 packet No [RFC4385]Figure 9: PW Channel Type Registry
IANA also made a brand-new registry, the Associated Channel Header TLV Registry. Its allocation policy is IETF review. This registry MUST record the following information. There are no initial entries, so it starts out totally empty. ✨
Name Type Length Description Reference
(octets)Figure 10: ACH TLV Registry
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
- [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
- [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.
- [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
- [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 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.
11.2. Informative References
- [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
- [BFD-VCCV] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, May 2009.
- [G805] International Telecommunication Union, "Generic Functional Architecture of Transport Networks", ITU-T G.805, March 2000.
- [MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", Work in Progress, November 2008.
- [OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for OAM in MPLS Transport Networks", Work in Progress, March 2009.
- [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
- [TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", Work in Progress, May 2009.
Authors' Addresses 💌
Matthew Bocci (editor) 🌸
Matthew Bocci (editor)
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
UK
EMail: matthew.bocci@alcatel-lucent.comMartin Vigoureux (editor) 🧚
Martin Vigoureux (editor)
Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
EMail: martin.vigoureux@alcatel-lucent.comStewart Bryant (editor) 👑
Stewart Bryant (editor)
Cisco Systems
EMail: stbryant@cisco.com📦 where this page comes from
- ietf: rfc5586 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms