RFC 7212
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 🎀
Okay bestie, this is RFC 7212 💖, and it's all about the MPLS Generic Associated Channel (G-ACh) Advertisement Protocol. It's a Standards Track document 👑, published in June 2014 under ISSN 2070-1721 ✨. The authors are D. Frost (Blue Sun), S. Bryant (Cisco Systems), and M. Bocci (Alcatel-Lucent) 🫶. The title block doesn't list anything it obsoletes or updates, so this RFC is standing on its own 💅.
Abstract
Okay so the G-ACh is an auxiliary logical data channel, and it's attached to a Label Switched Path (LSP), a pseudowire, or a section (link). Lots of different protocols can flow over it 🦋. Most of the time they're doing Operations, Administration, and Maintenance (OAM) work for the main data channel 🔧. This document gives you simple procedures so an endpoint of an LSP, pseudowire, or section can tell the other endpoints about its capabilities, its configuration parameters, or other application-specific info 📣. The receiver can then use that info to check or tweak its own local config, and operators can use it for diagnostics 🔍. It's giving helpful and low-drama 💅.
Status of This Memo
This is an Internet Standards Track document 🌈.
This document is a product of the Internet Engineering Task Force (IETF) 🧚. It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. If you want more on Internet Standards, check out Section 2 of RFC 5741 📚.
For the current status of this document, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc7212 🔗.
Copyright Notice
Copyright (c) 2014 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 they stood on the publication date 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💀.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 8
3.2. Applications Data Block . . . . . . . . . . . . . . . . . 9
3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 10
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 10
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 11
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 11
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 12
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 13
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 14
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Message Transmission . . . . . . . . . . . . . . . . . . 14
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 15
6. Message Authentication . . . . . . . . . . . . . . . . . . . 16
6.1. Authentication Key Identifiers . . . . . . . . . . . . . 16
6.2. Authentication Process . . . . . . . . . . . . . . . . . 17
6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 18
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Associated Channel Type Allocation . . . . . . . . . . . 20
10.2. Allocation of Address Family Numbers . . . . . . . . . . 20
10.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 221. Introduction ✨
The MPLS G-ACh is defined and described in [RFC5586] 📖. It gives you an auxiliary logical data channel for all kinds of protocols 🌸. Every one of those data channels is tied to an MPLS Label Switched Path (LSP), a pseudowire, or a section (link) 🔗. A big reason the G-ACh and its protocols exist is to provide Operations, Administration, and Maintenance (OAM) [RFC6291] capabilities for that LSP, pseudowire, or section 🛠️. Some examples are Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and throughput measurement [RFC6374] 📊. OAM functions built for the MPLS Transport Profile (MPLS-TP) [RFC5921] count too 💜.
This document lays out how an MPLS Label Switching Router (LSR) advertises its capabilities and configuration parameters, or other application-specific info, to its peers over LSPs, pseudowires, and sections 📣. Receivers can use that info to validate or adjust their own configs, and network operators can use it to find faults and config mismatches between endpoints 🕵️♀️. Quick heads up: in this document, "application" means an application that uses the protocol defined here (so it runs over the G-ACh), and it's not an end-user app 🙅♀️.
The main principle behind the MPLS G-ACh Advertisement Protocol (GAP) is simplicity 🫧. GAP is a one-way way to distribute info about the sender 📤. What a receiver does with that info is up to the receiver, a local matter 🏠. The data elements GAP distributes are application specific, and apart from the ones tied to GAP itself, they're outside this document's scope 🧩. IANA made a registry so GAP applications can be defined whenever they're needed 🗂️.
Assigning application identifiers and GAP parameters for protocols other than GAP itself is also outside this document's scope 🙃. Those assignments can happen in later documents, following the IANA considerations written here 📝.
1.1. Motivation
It's really useful in a network for a node to know general info about its adjacent nodes, meaning the nodes it has links to 🧠. At the very least, this lets a human operator or management app with access to the node see which adjacent nodes it can see, which is a lifesaver when you're troubleshooting connectivity 🆘. A classic "adjacency awareness protocol" is the Link Layer Discovery Protocol [LLDP] 🐍. It can share things about adjacent nodes in Ethernet networks, like system name, basic functional capabilities, link speed/duplex settings, and maximum supported frame size 💻. That data helps humans diagnose stuff and helps machines catch config mismatches automatically 🤖.
In MPLS networks, the G-ACh is a handy, link-layer-agnostic way for LSRs that are adjacent at the link layer to talk to each other 💬. So the G-ACh advertisement protocol in this document lets LSRs swap info similar to what LLDP handles for Ethernet links 🔁. GAP doesn't depend on which link-layer protocol is in use, though, and it can advertise info for any MPLS application 🌍.
In networks based on MPLS-TP [RFC5921] that don't also support IP, the usual protocols for finding the Ethernet address of an adjacent MPLS node aren't available 😭. Those include the Address Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery [RFC4861]. One possible use of the G-ACh advertisement protocol is finding the Ethernet media access control addresses of MPLS-TP nodes that don't have IP capability [RFC7213] 🔍. But if the only thing LSRs need to swap over an Ethernet link is their Ethernet addresses, the operator might just use LLDP for that instead 🎯.
GAP isn't limited to link-layer adjacency, whether you're talking about where messages go or what's in them 🌈. The G-ACh exists for any MPLS LSP or pseudowire, so GAP messages can go to remote LSP or pseudowire endpoints too 🛰️. GAP message content is extensible in a simple way and can carry any kind of info that could help MPLS LSRs connected by links, LSPs, or pseudowires 🎁. For example, in networks that use the G-ACh for OAM, GAP messages might tell adjacent LSRs about a node's OAM capabilities and config parameters 🛠️✨.
1.2. Terminology
Here's the glossary, because acronyms are a whole thing 💅:
Term Definition
----- -------------------------------------------
G-ACh Generic Associated Channel
GAL G-ACh Label
GAP G-ACh Advertisement Protocol
LSP Label Switched Path
OAM Operations, Administration, and Maintenance1.3. Requirements Language
Okay, this part is the rulebook for the requirement words 📏. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
2. Overview ✨
okay so the G-ACh Advertisement Protocol (GAP) has a super simple one-way vibe 💖. A device set up to send info for a certain data channel (an MPLS LSP, a pseudowire, or a section) just keeps sending GAP messages over the G-ACh tied to that channel 🦋. Each GAP message carries a bunch of Type-Length-Value (TLV) objects, sorted out per application 🎀. There's an IANA registry for identifying specific applications 📋. Application TLV objects are mostly static data the receiver is supposed to hang onto for a while, but they can also be metadata or special processing instructions 🧚.
Each GAP message can carry data for several applications at once 🌈. A sender can do a targeted update that refreshes just some of the applications, and the data for the others from an earlier message stays untouched 💅. GAP messages get processed in the order they arrive ✨.
Here's an example GAP message with this data:
Application A: A-TLV4, A-TLV15, A-TLV9
Application B: B-TLV1, B-TLV3
Application C: C-TLV6,(the TLVx stuff is just an example GAP TLV, fr fr 🙈)
Then a second message might show up with this:
Application B: B-TLV7, B-TLV3When the receiver gets that second message, it keeps B-TLV1 from the first one and tacks B-TLV7 onto its B-database 🍓. What happens to the new B-TLV3 depends on the rules B set for that object type. It could replace the old one or get combined with it somehow 🤔. The second message doesn't touch the databases the receiver keeps for Applications A and C 💜.
The sender decides how fast GAP messages go out, and that rate can change over time and be different for each application 🌸. Every message includes, for each application it covers, a lifetime that tells the receiver how long to wait before tossing that application's data 🕰️.
GAP doesn't do fragmentation or reassembly, so if an application wants to send chunks bigger than the packet size allows, the application has to chop its data up itself 🔪. The application and the network operator are both responsible for making sure GAP doesn't clog up the link to the peer 🚧.
GAP is built for a unidirectional channel 🛤️. But if the channel is bidirectional, there are a few messages defined for going from the receiver back to the sender, which can make things more efficient 🚀. Those are optimizations, though, and the protocol doesn't need them to work 🫶.
3. Message Format 🎀
An Associated Channel Header (ACH) Channel Type has been allocated for GAP like this:
Protocol Channel Type
---------------------------------- ------------
G-ACh Advertisement Protocol 0x0059For this Channel Type, as noted in [RFC7026], the ACH SHALL NOT be followed by the ACH TLV Header defined in [RFC5586] 🙅♀️.
Anything in this document marked as Reserved or Resv is saved for future specs and MUST be set to zero 🔒. Every integer value for a field defined here SHALL be encoded in network byte order 🔢.
A GAP message is a fixed header followed by a GAP payload 🧁. The payload is an Application Data Block (ADB) made of one or more block elements 🍰. Each block element holds an application identifier, a lifetime, and zero or more TLV objects for the application it describes 💖.
Malformed GAP messages MUST be discarded by the receiver, although the receiver MAY log an error 📝. If the error gets logged remotely, a suitable form of rate limiting SHOULD be used so you don't end up flooding the network with logging messages 🚨.
Implementations of this protocol version MUST set reserved fields in the message formats below to all zero bits when sending, and they MUST ignore any value in those fields when receiving 🧼.
3.1. GAP Message Format
The figure below shows the format of a G-ACh Advertisement Protocol message, which comes right after the Associated Channel Header (ACH) 📐:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Application Data Block (ADB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: GAP Message Format
Here's what each field means 👀:
- Version (4 bits): the protocol version. It's set to zero 🔢.
- Reserved (12 bits): MUST be sent as zero 🫧.
- Message Length (16 bits): the size in octets of this message, i.e., the part of the packet that comes after the Associated Channel Header 📏.
- Message Identifier (MI) (32 bits): a unique ID for this message 🆔. To keep things disambiguated, a sender MUST NOT reuse an MI over a given channel until it's confident that the receiver has expired all the ADBs tied to it 🕊️. The only job of this field is duplicate detection when a message burst happens (Section 5.1) 💥.
- Timestamp: a 64-bit Network Time Protocol (NTP) transmit timestamp, as specified in Section 6 of [RFC5905] ⏰.
3.2. Applications Data Block
An ADB is one or more elements that look like this 🧩:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .Figure 2: Application Data Block Element
The fields work like this 🤓:
- Application ID (16 bits): says which application this element describes 🎯. There's an IANA registry tracking the values for this field. You can have more than one block element with the same Application ID in the same ADB, and block elements with different Application IDs can hang out together in one ADB too 👯. The protocol rules for the mechanism, including which ADB elements show up and which TLVs go in each element, get defined in the document that specifies the application-specific usage 📖.
- Element Length (16 bits): the total length in octets of this block element, counting the Application ID and Element Length fields too 📐.
- Lifetime field (16 bits): how long, in seconds, the receiver should keep the data in this message. In other words, it's the lifetime of the static data carried in this ADB's TLV set ⏳. For TLVs that aren't carrying static data, the Lifetime doesn't mean anything 🤷♀️. A sender says this by setting the Lifetime field to zero. If the Lifetime is zero, the receiver processes the TLVs in this ADB, and the data tied to those TLV types gets marked as expired right away 💀. If the ADB has no TLVs at all, the receiver expires all the data linked to TLVs that were sent to this application before 🧹.
The rest of the Application Data Block element is a sequence of zero or more TLV objects using the format in Section 3.3 🧃.
The scope of an ADB element is an application instance attached to a specific channel between a specific source-destination pair, and the Lifetime field specifies the lifetime of the ADB element data in that specific context. Basically, this is the lifetime for that exact context and nowhere else 🫶.
3.3. TLV Object Format
GAP TLV objects look like this 🧱:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: TLV Object Format
- Type (8 bits): identifies the TLV Object. It's scoped to a specific application, and each application creates an IANA registry to track its Type values 🏷️.
- Reserved (8 bits): MUST be sent as zero 🔒.
- Length (16 bits): the length in octets of the Value field. The Value field doesn't need to be padded for alignment 📏.
GAP messages don't have a checksum 🙈. If you want to validate message integrity, you should use the authentication procedures in Section 6 🔐.
4. G-ACh Advertisement Protocol TLVs 🧚
GAP has several TLV objects related to its own operation, and they all live under Application ID 0x0000 🌟. These objects are metadata and processing instructions, not static data meant to be kept around 🧭. When a GAP ADB element is present in a GAP message, it MUST come before the other elements 👑. This matters a lot for the Flush message to work right (Section 4.3) 🧹.
Any application using GAP automatically gets to use the facilities provided by Application 0x0000 💅.
Application 0x0000 GAP messages MUST be processed in the order they're received 📬.
4.1. Source Address TLV
okay so the Source Address object is basically the "hi, it's me 💁♀️" TLV. it tells everyone who's sending, and maybe which interface and which channel. here's the layout 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (16 bits) | Address Family (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Source Address TLV Format
The Address Family field tells you what kind of address you're looking at, and it SHALL be set to one of the assigned values in the IANA "Address Family Numbers" registry. no going rogue with random numbers, bestie 🙅♀️
In IP networks, a Source Address SHOULD be included in GAP messages and set to an IP address of the sending device. when the channel is a link, that address SHOULD be an address of the transmitting interface. ✨
In non-IP MPLS-TP networks, a Source Address SHOULD be included in GAP messages and set to the endpoint identifier of the channel. the formats of those channel identifiers SHALL be as given in Sections 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and Length fields shown in those sections). IANA has allocated Address Family Numbers for these identifiers too, so check Section 10.2 🌸
On multipoint channels, a Source Address TLV is REQUIRED. no skipping it there, periodt 💅
4.2. GAP Request TLV
this one is a little "pls send me an update RIGHT NOW" moment 🙏 the sender is asking the receiver to send an immediate unicast GAP update back to them. if the Length field is zero, that means "give me an update for all applications." otherwise the Value field lists the applications you want, as a sequence of Application IDs:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID 1 | Application ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: GAP Request TLV Format
the vibe here is "I just rebooted, I need the latest tea NOW" ☕ the point is to get an immediate send after something like a restart, instead of waiting for the next periodic update. applications have to figure out what's actually worth sending back. just because an Application ID shows up in a Request TLV doesn't mean the response will include info for that app. the responder can also throw in info for apps that weren't asked about 🎁
A receiver SHOULD discard GAP Request messages that arrive at a rate in excess of what is considered reasonable for the application. that's just basic boundaries, babe 🫶
For an Application ID 0x0000 GAP Request, it is meaningful to respond with the Source Address. 🧚
this TLV counts as part of the GAP, so it doesn't need to be kept around. the receiver is allowed to record that it showed up, though, for management purposes 📝
4.3. GAP Flush TLV
this is the "wipe it all, start fresh" TLV 🧹 it tells the receiver to flush the GAP data for every application tied to this (sender, channel) pair. it's a null object, meaning its Length is set to zero. no value, just vibes.
The GAP Flush instruction does not apply to data contained in the message carrying the GAP Flush TLV object itself. so whatever application data is in that same message SHALL be processed and retained by the receiver as usual. the flush doesn't eat its own message, lol 😭
The Flush TLV type is 2. 💜
this TLV counts as part of the GAP too, so it doesn't need to be retained. the reception of it can still be recorded for management purposes, same as before ✨
4.4. GAP Suppress TLV
okay this one is a polite "pls stop sending me GAP updates for a bit" 🙈 the receiver is asked to cease sending GAP updates back to the transmitter over the current channel for a specified duration. Duration is a 16-bit non-negative integer, measured in seconds.
here's the big thing: the receiver MAY accept and act on the request, MAY ignore the request, or MAY resume transmissions at any time, depending on implementation or configuration choices and local pragmatics. so it's a request, not a command. the receiver gets to decide 💁♀️
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: GAP Suppress TLV Format
If the Length is set to 2, meaning the list of Application IDs is empty, then suppression of ALL GAP messages is requested. otherwise, only the updates for the listed applications get suppressed. a Duration of zero cancels any existing suppress requests for the listed applications, so zero is basically "never mind, unmute me" 🔊
This object only really makes sense for point-to-point channels, or when the sender is receiving unicast GAP updates. 🦋
4.5. GAP Authentication TLV
this is where the security glam comes in 🔐 the GAP Authentication TLV is used to provide authentication and integrity validation for a GAP message. the format looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=4 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: GAP Authentication TLV Format
the data and procedures for this object are explained in Section 6. go read that, it's the good stuff 📖
5. Operation ✨
5.1. Message Transmission
okay, transmission time 📡 G-ACh Advertisement Protocol message transmission SHALL operate on a per-data-channel basis, and the operator should be able to configure it that way.
since GAP message transmission can be active for lots of logical channels on the same physical interface, message transmission timers SHOULD be randomized across the channels supported by a given interface. the goal is to lower the odds of big synchronized message bursts. nobody wants everyone talking at once 🙃
The Message Identifier (MI) uniquely identifies this message, and its value is set at the sender's discretion. it MUST NOT be assumed to be a sequence number, so don't go treating it like one 🚫 The scope of an MI is a channel between a specific source-destination pair.
The Timestamp field SHALL be set to the time at which this message is transmitted. ⏰
The Lifetime field of each Application Data Block element SHALL be set to the number of seconds the receiver is advised to retain the data associated with this message and application. 🧠
if the transmitter wants the data it sent in an ADB element to stick around, it must refresh that ADB element by sending another update. refresh times SHOULD be set so that at least three updates get sent before the Lifetime expires. for example, if the Lifetime is set to 210 seconds, then updates should be sent at least once every 60 seconds. the math is literally 210 ÷ 3 = 70, so every 60 gets you there with room to spare 🧮
A sender may signal that previously sent data SHOULD be marked as expired by setting the ADB element lifetime to zero, as described earlier in Section 3. 🪦
sometimes an application wants extra reliability for some of its data 🛡️ when that's the case, the transmitter MAY send several instances of the message in succession (for example, three), separated by a delay that's appropriate to, or specified by, the application. this might be used when sending a Flush instruction after a device reset, for example. the expectation is that the receiver will detect duplicates using the MI. ✨
5.2. Message Reception
now the receiving side 👂 G-ACh Advertisement Protocol message reception SHALL operate on a per-data-channel basis, and again the operator should be able to configure it that way.
when a G-ACh Advertisement Protocol message comes in with data for some application X, the receiver checks whether it can interpret X-data. if it can't, the receiver MAY retain this data for the number of seconds specified by the Lifetime field. even if it can't parse the data, it may still be useful to the operator 🔍
if the receiver CAN interpret X-data, it processes the data objects accordingly. the data for the ones that represent static data gets retained for the number of seconds in the Lifetime field. if the Lifetime is zero, that data is immediately marked as expired. and if no TLVs are specified, all data tied to previously received TLVs is marked as expired (Section 3). if one of the received TLV objects has the same Type as a previously received TLV, then the data from the new object SHALL replace the data associated with that Type, unless the X specification dictates a different behavior. so newest wins, unless the spec says otherwise 💅
The received data is made available to local applications that need it and are locally authorized to view it. how that happens is up to the receiver, and it's outside the scope of this document. not our problem, fr 🤷♀️
The receiver MAY make use of the application data contained in a GAP message to perform some level of auto-configuration, for example if the application is an OAM protocol. however, the application SHOULD take care to prevent oscillation, where each endpoint keeps adjusting its configuration to match the other one. 🌀 Any such auto-configuration based on GAP information MUST be disabled by default. default OFF, no surprises 🙅♀️
The MI may be used to detect and discard duplicate messages. 🧹
6. Message Authentication ✨
okay so the GAP has a whole authentication vibe 🔐💖 It makes sure messages are legit and haven't been messed with. You attach a GAP Authentication TLV and put a MAC (Message Authentication Code, a hash output computed with a secret key only the sender and receiver know) in its Authentication Data field. The receiver does the same math and compares. If the MACs don't match, the message gets tossed 🗑️ Using this is RECOMMENDED 💅
The rest of this section spells out how that works. It's based on the generic cryptographic authentication procedures for IS-IS (Intermediate System to Intermediate System) routing, described in [RFC5310]. Iconic borrowing, honestly 🙌
6.1. Authentication Key Identifiers
an Authentication Key Identifier (Key ID) is a 16-bit tag that the sender and receiver share, and it points to a set of authentication parameters 🎀 These parameters never go over the wire. Each node gets them through outside means, like explicit operator configuration or a separate key-exchange protocol. Several Key IDs can be active at once on both sides. The sender just picks one from that set for each outbound message. This is what makes key migration across the network possible, so it's giving smooth transitions 🦋
The parameters tied to a Key ID are:
- Authentication Algorithm: This tells you which algorithm to use to generate or interpret the authentication data. Right now the following values MAY be supported: HMAC-SHA-1, HMAC-SHA-256. HMAC-SHA-1 MUST be supported. 🔑
- Authentication Keystring: A secret octet string that is the basis for the cryptographic key used by the Authentication Algorithm. It SHOULD NOT be a human-memorable string 🙈 Implementations MUST be able to use random binary values of the appropriate length as a keystring. 🧚
Implementers SHOULD consider using [RFC7210] for key management 💜 If you do, authenticated information sent over the GAP MUST only be considered valid if it was sent during the Keying and Authentication for Routing Protocols (KARP) interval between SendLifetimeStart and SendLifeTimeEnd. But if the GAP TLV that carries it expires before KARP's SendLifetimeStart, the information is never used. And if it expires before KARP's SendNotAfter, the key becomes invalid when the GAP TLV expires. Timing is everything, bestie ⏰
At the time of writing, there are no mechanisms for dynamic key management when there's no IP. So key management in those environments has to happen through the equipment management system or some other out-of-band service. The MPLS layer is normally shielded from direct user access, so it's a relatively protected environment 🏰 That means key turnover is expected to be a relatively infrequent event 🌸
6.2. Authentication Process
the authentication process for GAP messages is pretty straightforward 💅 First, a Key ID gets associated, on both the sending and receiving nodes, with a set of authentication parameters. Then, when the sender makes a GAP message, it sets the Key ID field of the GAP Authentication TLV to match. (The length of the Authentication Data field is also known at this point, since it depends on the Authentication Algorithm.) The sender then computes a MAC for the message as described in Section 6.3 and fills the Authentication Data field with that MAC, overwriting the zeros that were used during the computation. Then the message gets sent 🦋
When the message arrives, the receiver computes a MAC for it as described below. It sets the Authentication Data field of the GAP Authentication TLV to all zeros before computing, too. Then it compares its computed MAC with the MAC received in the Authentication Data field. If the two are equal, authentication has succeeded. If not, it has failed 😤
This process makes sure messages are authentic and have integrity, but it's still vulnerable to a replay attack 💀 That's when a third party captures a message and sends it to the receiver later on. The GAP message header has a Timestamp field, which can be used to protect against replay attacks 🕰️ To get that protection, the receiver checks that the time recorded in the Timestamp field of a received and authenticated GAP message matches the current time, within a reasonable tolerance that allows for propagation delay. Then it accepts or rejects the message accordingly. Clock corrections SHOULD be monotonic to avoid replay attacks, unless operator intervention overrides the monotonic configuration setting to get faster convergence with the current time 🌈
If the clocks of the sender and receiver aren't synchronized with one another, then the receiver has to do the replay check against its best estimate of the current time according to the sender's clock. The timestamps in GAP messages can be used to infer the approximate clock offsets of senders. That doesn't give high-precision clock synchronization, but it's good enough for the replay check with an appropriately chosen tolerance ⭐
6.3. MAC Computation
The HMAC procedure described in [RFC2104] is what computes the MAC ✨
The Authentication Data field of the GAP Authentication TLV is set to all zeros. Then the MAC is computed over the entire GAP message, as shown in Figure 1 🧮
Where there is less data than is needed for the MAC computation, a value of zero MUST be used. 🫶
The length of the Authentication Data field is always less than or equal to the message digest size of the specific hash function in use. But implementers need to think about this: although MAC truncation makes the field smaller, it also means a corresponding drop in the strength of the assurance provided 📉
MAC truncation is NOT RECOMMENDED. 🙅♀️
7. Link-Layer Considerations 🔗
When GAP is used to support device discovery on a data link, GAP messages must be sent in a way that other listeners on the link can receive them without the sender knowing their link-layer addresses first. Basically, they have to be multicast 📣 Considerations for multicast MPLS encapsulation are covered in [RFC5332]. For example, Section 8 of [RFC5332] describes how destination Ethernet MAC addresses get selected for multicast MPLS packets. Since a GAP packet sent over a data link contains just one label, the G-ACh Label (GAL) with label value 13, the correct destination Ethernet address for frames carrying GAP packets meant for device discovery is 01-00-5e-80-00-0d, according to those selection procedures 💜
8. Manageability Considerations 🛠️
The data sent and received by this protocol MUST be made accessible for inspection by network operators. And where local configuration gets updated by received information, it MUST be clear why the configured value has changed 👀 This lets the operator see the operational parameters currently in use, and understand when local configuration has been superseded by inbound parameters from its peer 🧠
When a system restarts, any GAP application data and peer state data kept because of prior advertisements from GAP peers MUST be discarded. This stops incorrect operation based on stale data 🧹
All GAP applications MUST be disabled by default and need to be enabled by the operator if required 🔒
9. Security Considerations 🚨
Okay, this part is serious, bestie 😭 G-ACh Advertisement Protocol messages carry information about the sending device and its configuration, and it's sent in cleartext over the wire. If an unauthorized third party gets access to the MPLS data plane or the lower network layers between the sender and receiver, they can observe this information. In general though, the information in GAP messages is no more sensitive than what's in other protocol messages, like routing updates, which are commonly sent in cleartext. So no attempt is made to guarantee confidentiality of GAP messages. That means the GAP MUST NOT be used to send TLVs in cleartext where the value needs confidentiality, for example GAP or application TLVs containing 'bare' cryptographic keying material 🙅♀️🔑 Applications that need confidentiality will have to implement a suitable confidentiality method 🛡️
A bigger potential threat is GAP messages being sent by unauthorized sources, or messages being manipulated in transit. This can mess up what receivers believe about legitimate senders 🥺 To protect against this, the message authentication procedures (specified in Section 6) let receivers make sure GAP messages are authentic and have integrity. These procedures include ways to protect against replay attacks, where a third party captures a legitimate message and "replays" it to a receiver at some later time 🔁
10. IANA Considerations 📋
10.1. Associated Channel Type Allocation
IANA has allocated an entry in the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry for the "G-ACh Advertisement Protocol", as follows:
Value Description Reference
------ ---------------------------- ---------
0x0059 G-ACh Advertisement Protocol This RFCThe reader should note that the "TLV Follows" column in the registry has been deleted [RFC7026] 📝
10.2. Allocation of Address Family Numbers
IANA has allocated three entries from the Standards Track range in the "Address Family Numbers" registry for MPLS-TP Section, LSP, and Pseudowire endpoint identifiers, per Section 4.1. The allocations are:
Number Description Reference
------ -------------------------------------- ---------
26 MPLS-TP Section Endpoint Identifier This RFC
27 MPLS-TP LSP Endpoint Identifier This RFC
28 MPLS-TP Pseudowire Endpoint Identifier This RFC10.3. Creation of G-ACh Advertisement Protocol Application Registry
IANA has created a new registry, "G-ACh Advertisement Protocol Application Registry" in the "Generic Associated Channel (G-ACh) Parameters" registry, with fields and initial allocations as follows:
Application ID Description Reference
-------------- ---------------------------- ---------
0x0000 G-ACh Advertisement Protocol This RFCThe range of the Application ID field is 0x0000 - 0xFFFF 🔢
The allocation policy for this registry is IETF Review ✨
10.4. Creation of G-ACh Advertisement Protocol TLV Registry 🎀
okay so bestie, IANA made a brand new registry 📋✨ it's called "G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)" and it lives inside the "Generic Associated Channel (G-ACh) Parameters" registry. it's giving organized 💅
here's the initial lineup, all of them pointing back to this RFC:
Type Name Type ID Reference
------------------ ------- ---------
Source Address 0 This RFC
GAP Request 1 This RFC
GAP Flush 2 This RFC
GAP Suppress 3 This RFC
GAP Authentication 4 This RFCthe Type ID field can hold anything from 0 to 255 🔢 and the allocation policy for this registry is IETF Review 🫶
11. Acknowledgements 🌸
we thank Adrian Farrel for his valuable review comments on this document 🙏💖 he was such a sweetie for reviewing it!
12. References 📚
12.1. Normative References 🔥
[RFC2104]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC5332]Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.[RFC5586]Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.[RFC5905]Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.[RFC6428]Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.[RFC7210]Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, April 2014.
12.2. Informative References 💜
[LLDP]IEEE, "Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, September 2009.[RFC0826]Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.[RFC4861]Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.[RFC5085]Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.[RFC5310]Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.[RFC5884]Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.[RFC5921]Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.[RFC6291]Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.[RFC6374]Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.[RFC7026]Farrel, A. and S. Bryant, "Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel", RFC 7026, September 2013.[RFC7213]Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop Ethernet Addressing", RFC 7213, June 2014.
Authors' Addresses 🦋
Dan Frost
Blue Sun
EMail: frost@mm.stStewart Bryant
Cisco Systems
EMail: stbryant@cisco.comMatthew Bocci
Alcatel-Lucent
EMail: matthew.bocci@alcatel-lucent.comThat's the whole RFC, bestie! 🌈✨ We made it through all five parts 😭🫶
📦 where this page comes from
- ietf: rfc7212 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms