RFC 6812
Cisco Service-Level Assurance Protocol
RFC 6812: Cisco Service-Level Assurance Protocol 🎀
okay bestie, let's get into it. this is RFC 6812, and it's giving performance measurement realness 💅
Title block, the tea ☕
- Stream: Independent Submission
- Request for Comments: 6812
- Category: Informational
- ISSN: 2070-1721
- Authors: M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli
- Organisation: Cisco Systems
- Date: January 2013
- Obsoletes / Updates: the header doesn't list anything for either one 🤷♀️
Abstract
so Cisco's Service-Level Assurance Protocol (aka Cisco's SLA Protocol) is a Performance Measurement protocol that's been widely deployed 🔥. it measures service-level stuff like network latency, delay variation, and packet/frame loss. this doc describes the Cisco SLA Protocol Measurement-Type UDP-Measurement so vendors can actually talk to each other 🤝
Status of This Memo
not an Internet Standards Track spec, it's just published for info vibes ✨
this is an independent contribution to the RFC Series, not part of any other RFC stream. the RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment 💀. docs approved for publication by the RFC Editor aren't a candidate for any level of Internet Standard, see Section 2 of RFC 5741.
for the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6812 🦋
Copyright Notice
Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the publication date. read those carefully, they spell out your rights and restrictions for this doc 📜
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Control Phase . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Control-Request Message . . . . . . . . . . . . . . . 7
3.1.1.1. Command-Header . . . . . . . . . . . . . . . . . . 8
3.1.1.2. CSLDs . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Control-Response Message . . . . . . . . . . . . . . . 15
3.2. Measurement Phase . . . . . . . . . . . . . . . . . . . . 16
4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 19
5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Message Authentication . . . . . . . . . . . . . . . . . . 24
7.2. IPsec Considerations . . . . . . . . . . . . . . . . . . . 24
7.2.1. Control Traffic . . . . . . . . . . . . . . . . . . . 24
7.2.2. Measurement Traffic . . . . . . . . . . . . . . . . . 24
7.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 261. Introduction ✨
active network performance measurements are huge for admins keeping an eye on network health 👀. as service providers try to stand out, performance measurement is becoming a must-have tool for watching service-level guarantees and, generally, keeping the network healthy 💖
performance metrics, both one-way and two-way, can be used for pre-deployment validation and also for measuring in-band live network-performance characteristics 🌈. they work for service levels in L2 and L3 networks, plus apps running on top of L3. active measurements are gathered by analysing synthetically generated request and response packets or frames. this is the opposite of passive measurements, which analyse live traffic flowing through a particular network element 🔍
there's a growing body of Performance Measurement standards work that lets different vendors' network elements interoperate, by describing common measurement protocols and metrics 🫶. the IETF has actively developed Standards Track docs on this, like "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] and "Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] 🌸
Cisco's SLA Protocol is another Performance Measurement protocol, with a rich set of measurement message types 💜. the types can be sorted into two buckets: the ping-like ones that test connectivity by giving round-trip or one-way latency, and the ones that give a richer set of stats, including network jitter and packet or frame loss. each active measurement exchange mimics an actual protocol exchange, so it's realistic af 🧚
Cisco's SLA Protocol UDP-Measurement message exchanges, as covered in this doc to enable interoperability, simulate a UDP application 🦋. they can simulate either Voice or Video traffic that's encoded in RTP frames within UDP envelopes 🎀. the Measurement-Type UDP-Measurement message exchanges carry the info needed to derive a robust set of statistics, which is honestly iconic 👑
2. Terminology 📖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in RFC 2119 [RFC2119]. these are the official BCP 14 words, so they carry real weight 🔥
here's the glossary, bestie 💅
+-------------+-----------------------------------------------------+
| Term | Description |
+-------------+-----------------------------------------------------+
| Control | A phase during which a Control-Request and Control- |
| Phase | Response are exchanged. |
| --------- | -------------------------- |
| L2 | OSI Data-Link Layer |
| --------- | -------------------------- |
| L3 | OSI Network Layer |
| --------- | -------------------------- |
| Measurement | Active Measurement Phase that is marked by a |
| Phase | sequence of Measurement-Request and Measurement- |
| | Response exchanges. |
| --------- | -------------------------- |
| Metric | A particular characteristic of the network data |
| | traffic, for example, latency, jitter, packet or |
| | frame loss. |
| --------- | -------------------------- |
| Responder | A network element that responds to a message. |
| --------- | -------------------------- |
| RTP | Real-time Transport Protocol |
| --------- | -------------------------- |
| Sender | A network element that is the initiator of a |
| | message exchange. |
| --------- | -------------------------- |
| Service- | This is the level of service that is agreed upon |
| Level | between the Provider and the Customer. |
| --------- | -------------------------- |
| UDP | User Datagram Protocol |
+-------------+-----------------------------------------------------+3. Protocol 🧠
the Cisco SLA Protocol has two distinct phases: the Control Phase and the Measurement Phase 💖. each phase is made of info exchanged between a network element acting as the Sender and an element designated as the Responder 🫶
the Control Phase is the first phase of message exchanges and it forms the base protocol 👑. this phase establishes the identity of the Sender and provides info for the Measurement Phase. it's marked by a single message pair of Control-Request and Control-Response. the Sender kicks things off with a Control-Request, and the Responder acknowledges it with a Control-Response ✨. the Control-Request may be sent multiple times if a Control-Response hasn't been received, and the number of retries is configurable on the Sender element 🔁
the Measurement Phase is the second phase, made of a sequence of Measurement-Request and Measurement-Response messages 🌈. these may be exchanged as often as required. each Measurement-Request gets acknowledged by the Responder with a Measurement-Response 💜
the number and frequency of messages SHOULD be controlled by configuration on the Sender element, along with the waiting time for a Control-Response 🎀. (that's the official BCP 14 SHOULD, so don't skip it, periodt 💅)
here's the sequence diagram showing how the message exchanges go down 🦋
+-+-+-+-+-+-+-+ Control-Request +-+-+-+-+-+-+-+
| | | |
| Sender | | Responder |
| | | |
| | | |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| |
| Control-Request |
| -------------------------------------------->|
| |
| Control-Response |
|<---------------------------------------------|
| |
| |
| Measurement-Request(1) |
| -------------------------------------------->|
| |
| Measurement-Response(1) |
|<---------------------------------------------|
| |
. .
. .
. .
. .
. Measurement-Request(n) .
| -------------------------------------------->|
| |
| Measurement-Response(n) |
|<---------------------------------------------|
| |okay the Control Phase is up next, and it's where the real details start 🌸💖
3.1. Control Phase
Okay so the Control Phase is where the Sender kicks things off by sending a Control-Request to the Responder 💌. That message goes to UDP port 1167 on the Responder and asks it to open a Measurement Phase UDP port. It also says how long that port needs to stay open ⏰. The Responder replies with a Control-Response. If the Sender's identity checks out and the port actually opens, the Status is Success 🎉. In every other case, the Responder puts a non-zero Status in the Command-Header Status field 🙅♀️.
The exchange goes like this 👇
+-+-+-+-+-+-+-+ Control-Request +-+-+-+-+-+-+-+
| |------------------------------->| |
| Sender | | Responder |
| | Control-Response | |
| |<-------------------------------| |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+3.1.1. Control-Request Message
The Control-Request message is a Command-Header followed by one or more Command, Status, Length and Data sections, which we'll call CSLD for short 🧁. Lowkey the important bit: there SHOULD be at least two CSLD sections. One is the authentication CSLD, and the other carries the info for the Measurement Phase simulation type 🔐.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Command-Header |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1.1.1. Command-Header
The Command-Header is the very first section of the Control-Request message, and it 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send Timestamp |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 📖
+-----------+-----------+-------------------------------------------+
| Field | Size | Description |
| | (bits) | |
+-----------+-----------+-------------------------------------------+
| Version | 8 | Current version supported and is to be |
| | | set to 2. |
| --------- | --------- | -------------------------- |
| Reserved | 8 | Reserved field, MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Status | 16 | Indicates success or failure for the |
| | | entire message. In a Control-Request, the|
| | | value of the Status field is ignored by |
| | | the receiver and SHOULD be set to 0. |
| --------- | --------- | -------------------------- |
| Sequence | 32 | Used to map requests to responses. This |
| Number | | is a monotonically increasing number. |
| | | Implementations MAY reset the sequence |
| | | number to 0 after a reboot, and it SHOULD |
| | | wrap around after all bits have been |
| | | exceeded. |
| --------- | --------- | -------------------------- |
| Total | 32 | Carries the total length of the Control |
| Length | | message in number of octets. |
| --------- | --------- | -------------------------- |
| --------- | --------- | -------------------------- |
| Send | 64 | This field is set to the time the command |
| Timestamp | | was submitted for transmission and is |
| | | updated for a response. This field MAY |
| | | be used when security is of concern in |
| | | order to prevent replay attacks. SHOULD |
| | | be updated when the response is sent. |
| | | When not being used, it MUST be set to all|
| | | 0's. The format is as given in RFC 5905. |
+-----------+-----------+-------------------------------------------+The Sequence Number field MUST include a brand-new number for every new request, and it's monotonically increasing 📈. If the Control-Request needs a retry, the sequence number MUST remain unchanged 🔁. Don't touch it!
3.1.1.2. CSLDs
The ordered list of the two CSLDs that go along with the Command-Header is:
- The Authentication CSLD
- A Measurement-Type CSLD
In this revision of the protocol, there's only one Measurement-Type CSLD defined, and that's the UDP-Measurement CSLD 🎯. More can be added later for future extensions, so it's giving "room to grow" 🌱. If you want the deets on extensions, check out Section 5 📚.
3.1.1.2.1. Authentication CSLD ✨
okay bestie, the Authentication CSLD is literally the bouncer at the door 💅 it does two jobs: it authenticates the message, and it checks that the requester actually knows the shared secret 🔐 no cap, this is the main character of the CSLD world 👑 here's how it's laid out:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command = 1 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Reserved | Key Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Random Number +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
. .
. .
. Message Authentication Digest .
. .
. .
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields and what they mean are all in this table 🎀
+----------------+-----------+--------------------------------------+
| Field | Size | Description |
| | (bits) | |
+----------------+-----------+--------------------------------------+
| Command | 16 | Indicates the CSLD is of type |
| | | Authentication. |
| --------- | --------- | -------------------------- |
| Status | 16 | Not used for a request and MUST be |
| | | set to 0. |
| --------- | --------- | -------------------------- |
| Command-Length | 32 | Indicates the length of the CSLD in |
| | | octets. |
| --------- | --------- | -------------------------- |
| Mode | 8 | Indicates the type of authentication |
| | | being used and is set as follows: |
| | | 0 - No Authentication, |
| | | 1 - SHA256 Authentication, |
| | | 2 - HMAC-SHA-256 |
| --------- | --------- | -------------------------- |
| Reserved | 8 | This field is reserved for future |
| | | extensions and MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Key ID | 16 | Indicates the index number of the |
| | | shared secret to be used for |
| | | authenticating the Control-Request |
| | | message. |
| --------- | --------- | -------------------------- |
| Random Number | 128 | This field is to be unique over the |
| | | shared-secret life and is used to |
| | | make it difficult to predict the |
| | | shared secret via multiple packet |
| | | captures. The value is reflected in |
| | | a response message. This field MAY |
| | | be used when security is of concern |
| | | and is useful to prevent dictionary |
| | | attacks. When not being used, it |
| | | should be set to all 0's |
| --------- | --------- | -------------------------- |
| Message | 256 | Contains the message authentication |
| Authentication | | digest and is computed over the |
| Digest | | entire control packet, including this|
| | | field set to all 0s. |
+----------------+-----------+--------------------------------------+the Status and Reserved fields are both on the MUST-be-0 list, so don't get creative with those 🙈
the random number is the spicy part 🌶️ it's 128 bits, it's meant to be unique over the whole life of the shared secret, and it's there so the secret is harder to predict even if someone is collecting packet captures 🦋 it MAY be used whenever security is a concern, and it's especially useful against dictionary attacks ✨ if you're not using it, it should be all 0's 🫶
and the digest is the grand finale 💖 it's 256 bits, it holds the message authentication digest, and it gets computed over the entire control packet while this field is still all 0s 🧚
3.1.1.2.2. UDP-Measurement CSLD 🦋
okay so the UDP-Measurement CSLD is the one that sets up the UDP measurement stuff bestie 🫶 it tells everyone which Measurement-Type to use during the Measurement Phase, which addresses and UDP port get opened, and how long that port has to stay open for the Measurement Phase ⏳ main character energy for sure 💅 here's how the CSLD is laid out:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command = 2 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Role | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Control Source Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Control Destination Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Measurement Source Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Measurement Destination Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Source Port | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Source Port | Measurement Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Duration is specified in milliseconds. ⏱️
Next up, the field-by-field breakdown 🎀 this is where it gets juicy, so grab a snack 🍓
+-------------+-----------+-----------------------------------------+
| Field | Size | Description |
| | (bits) | |
+-------------+-----------+-----------------------------------------+
| Command | 16 | Indicates that the CSLD is to simulate |
| | | UDP traffic measurements. |
| --------- | --------- | -------------------------- |
| Status | 16 | Not used for a request and MUST be set |
| | | to 0. |
| --------- | --------- | -------------------------- |
| Command- | 32 | Indicates the length of the CSLD in |
| Length | | octets. |
| --------- | --------- | -------------------------- |
| Address | 8 | Indicates the address type and is set to|
| Type | | one of the values in the "Cisco SLA |
| | | Protocol Address Family Registry": |
| | | 2 - IPv4 addresses, 3 - IPv6 addresses. |
| --------- | --------- | -------------------------- |
| Role | 8 | Indicates the role of the endpoint |
| | | receiving the Control message and is |
| | | set as follows: 1 - Responder. |
| --------- | --------- | -------------------------- |
| Reserved | 16 | Reserved and MUST be set to 0. |
| --------- | --------- | -------------------------- |
| --------- | --------- | -------------------------- |
| Session | 32 | Carries a session identifier that is a |
| Identifier | | locally significant unique value to the |
| | | originator of the message. MUST be 0 |
| | | when not specified. |
| --------- | --------- | -------------------------- |
| Control | 128 | Set to the address from which the |
| Source | | Sender initiates Control messages. For |
| Address | | IPv4 addresses, only the first 32 bits |
| | | are filled and the remaining bits MUST |
| | | be set to 0. |
| --------- | --------- | -------------------------- |
| Control | 128 | Set to the address on the Responder |
| Destination | | where the Control message will be sent. |
| Address | | For IPv4 addresses, only the first 32 |
| | | bits are filled and the remaining bits |
| | | MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Measurement | 128 | Set to the address of the Sender from |
| Source | | where the measurement packets will |
| Address | | originate. For IPv4 addresses, only the|
| | | first 32 bits are filled and the |
| | | remaining bits MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Measurement | 128 | Set to the address on the Responder |
| Destination | | towards which the measurement packets |
| Address | | will be sent and is a way to identify |
| | | an ingress interface on the Responder. |
| | | For IPv4 addresses, only the first 32 |
| | | bits are filled and the remaining bits |
| | | MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Control | 16 | Indicates the port on the Sender from |
| Source Port | | which the Control message is sent. If |
| | | not set, the value should be derived |
| | | from the incoming packet. |
| --------- | --------- | -------------------------- |
| Reserved | 16 | Reserved Field, MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Measurement | 16 | Indicates the UDP Port on the Sender |
| Source Port | | from which the measurement packets will |
| | | be sent. |
| --------- | --------- | -------------------------- |
| Measurement | 16 | Indicates the UDP Port on the Responder |
| Destination | | towards which the measurement packets |
| Port | | will be sent. |
| --------- | --------- | -------------------------- |
| --------- | --------- | -------------------------- |
| Duration | 32 | This is the duration in milliseconds |
| | | that the port needs to be kept open for |
| | | accepting Measurement Phase messages. |
| | | Measurement messages received after the |
| | | duration MUST be ignored. |
+-------------+-----------+-----------------------------------------+Heads up, bestie 🙈 the source addresses are only there to show who the originator is. In a NAT environment they can't be used as a destination address for responses, so don't go sending replies back to them 💀
3.1.2. Control-Response Message
Okay bestie, so when the Responder gets the Control-Request, it sends back a Control-Response 💌 It reflects the Command-Header with an updated Status field, and it includes the two CSLD sections, which also get updated Status fields ✨ The layout is literally identical to the Control-Request, so there's no new format to learn 🫶
Here's the Status value tea 🍵
+-----------+-------------------------------------------------------+
| Status | Description |
| Value | |
+-----------+-------------------------------------------------------+
| 0 | Success |
| --------- | -------------------------- |
| 1 | Fail - catch all |
| --------- | -------------------------- |
| 2 | Authentication Failure |
| --------- | -------------------------- |
| 3 | Format error - sent when any CSLD type is not |
| | recognized or any part of a CSLD has a value that is |
| | not recognized |
| --------- | -------------------------- |
| 4 | Port in use - the UDP/TCP port is already being used |
| | by some other application and cannot be reserved |
| --------- | -------------------------- |
| 5+ | Future extension and experimental values; refer to |
| | the "Cisco SLA Protocol Status Types Registry" in the |
| | Considerations section (Section 6). |
+-----------+-------------------------------------------------------+These Status values work for both the Command-Header and the CSLD sections 💅 In a Command-Header, the Status only comes out as Success if every CSLD section is also Success 🥺 If even one CSLD isn't, the Command-Header Status gets set to non-zero 💀 The Command-Header Status field SHOULD only make use of status values 0 through 3 🌸 CSLDs, on the other hand, can use the other values too when they apply ✨ Future extensions MAY extend these values as appropriate 🦋
The Control-Response message, aside from updating the Status fields, SHOULD also update the Sent Timestamp (if used) in the Command-Header, plus the Message Authentication Digest in the Authentication CSLD 🙈 That digest gets computed the same way as it was for the Control-Request message 🔥 The Random Number field MUST be reflected without modification 🎀 And the Session Identifier MAY be updated to a locally significant unique value, but it MUST be 0 if not specified 👑 Main character energy for the Random Number, no notes 💜
3.2. Measurement Phase
Okay so once the Control-Response comes back with Status set to Success 🎉, we move on to the second phase, the Measurement Phase 🦋. If the Status is anything other than Success, no measurement traffic starts at all, bestie 💀. In this phase the Sender sends a whole stream of measurement messages, spaced a configured number of milliseconds apart ✨.
+-+-+-+-+-+-+-+ Measurement-Request(n) +-+-+-+-+-+-+-+
| |------------------------------->| |
| Sender | | Responder |
| | Measurement-Response(n) | |
| |<-------------------------------| |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+The UDP-Measurement message format is the same in both directions 🔁. It's the same going from the Sender to the Responder and coming back from the Responder to the Sender. The only thing that changes is the stuff with the Responder prefix, which gets updated along the way. Every other field MUST remain unchanged 🙅♀️. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement-Type = 3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Send Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Receive Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Send Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Receive Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Clock Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Clock Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Sequence No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now let's look at what each field means for the UDP-Measurement Measurement-Request 🧐:
+-------------+-----------+-----------------------------------------+
| Field | Size | Description |
| | (bits) | |
+-------------+-----------+-----------------------------------------+
| Measurement-| 16 | Carries the type of measurement being |
| Type | | performed; 1 - Reserved, 2 - Reserved, |
| | | 3 - UDP-Measurement |
| --------- | --------- | -------------------------- |
| Reserved | 16 | Reserved field and MUST be set to 0. |
| --------- | --------- | -------------------------- |
| Sender Send | 64 | Carries the timestamp when the |
| Time | | measurement message was submitted for |
| | | transmission by the Sender. |
| --------- | --------- | -------------------------- |
| Responder | 64 | Carries the timestamp when the |
| Receive | | measurement message was received by |
| Time | | the Responder. |
| --------- | --------- | -------------------------- |
| Responder | 64 | Carries the timestamp when the |
| Send Time | | measurement message was submitted for |
| | | transmission by the Responder. It MUST |
| | | be 0 in the Sender-to-Responder |
| | | direction. |
| --------- | --------- | -------------------------- |
| Sender | 64 | Carries the timestamp when the Sender |
| Receive | | received the measurement message. It |
| Time | | MUST be 0 in both directions on the |
| | | wire and is filled on the Sender side |
| | | as soon as the measurement message is |
| | | received. |
| --------- | --------- | -------------------------- |
| Sender | 64 | Gives an estimate of the Sender clock |
| Clock | | skew measured in seconds and fractional |
| Offset | | seconds. |
| --------- | --------- | -------------------------- |
| Responder | 64 | Gives an estimate of the Responder |
| Clock | | clock skew measured in seconds and |
| Offset | | fractional seconds. |
| --------- | --------- | -------------------------- |
| Sender | 32 | The sequence number of the measurement |
| Sequence | | message on the Sender side. This field |
| Number | | is monotonically increasing and MAY |
| | | wrap around. |
| --------- | --------- | -------------------------- |
| --------- | --------- | -------------------------- |
| Responder | 32 | The sequence number of the measurement |
| Sequence | | message on the Responder side. This |
| Number | | field is monotonically increasing and |
| | | MAY wrap around. |
| --------- | --------- | -------------------------- |
| Data | 32 bit | This field is used to pad up to the |
| | aligned | configured request data size. The |
| | | minimum size for this field SHOULD be |
| | | 64 octets. |
+-------------+-----------+-----------------------------------------+Note: All timestamps have the default format as described in RFC 5905 [RFC5905] ⏰. It goes like this: the first 32 bits are the unsigned integer number of seconds elapsed since 0 h on 1 January 1900, and the next 32 bits are the fractional part of a second. The timestamp definition is also similar to the one in RFC 4656 [RFC4656] 🕰️.
The timestamp format can also be the low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588] 🧠. This truncated version is a 32-bit seconds field followed by a 32-bit nanoseconds field, and it's the same as the IEEE 1588v1 timestamp format. It's similar to the default timestamp in RFC 6374 [RFC6374] 💜.
Here's the big rule 📢: implementations MUST use only one of the two formats. The one you pick gets negotiated out-of-band between the endpoints, or it defaults to the format in RFC 5905 [RFC5905] 🤝.
4. Implementation Notes ✨
Okay, implementation tips time 🛠️. Responder implementations SHOULD support simultaneous measurements aimed at a single port, whether they come from the same Sender or from different ones 🚦. If different measurement instances come from the same Sender, there MUST be a clear way for the Responder to tell the traffic apart 🕵️♀️. An example would be a unique 5-tuple of protocol, source address, source port, destination address, and destination port.
A Control-Request for the same Measurement-Type request, identified by those 5-tuples, for instance, SHOULD result in the duration timer being reset, along with the Responder sequence number ⏱️.
You can repeat a Control Phase followed by the Measurement Phase 🔁. That's how you get a continuous measurement across the whole lifetime of a device 💖.
The Authentication CSLD MUST always be included 🔐. The Random Number field is there to stop dictionary attacks 🛡️, and it should be set to a random value wherever security matters.
An implementation MUST include the Random Number and Message Authentication fields when the mode is non-zero 🙌. The fields MAY be included when the mode is set to 'No Authentication', but if they are present, they MUST be set to 0. For the SHA256 authenticator mode, the shared secret gets prepended to the Control message, and then the authentication algorithm runs over all the data, including the shared secret 🧁. SHA256 mode is included for ease of implementation, but the HMAC variant is strongly recommended for stronger security 💪.
If the UDP port in the UDP-Measurement CSLD is busy, the Responder MAY suggest an alternative port 🔄. In that case, the Status of the UDP-Measurement CSLD MUST be set to Success. The Sender MAY set the field to 0, and then the Responder MAY choose to open a port and send it back along with a Status of Success. Heads up, this has security ramifications, so the Responder needs to pick the port very carefully 🚨.
⚠️ Picking a port is a security decision, not just a convenience. Be picky about it, bestie 💅.
The measurement stream usually has packets or frames with a periodic inter-packet distribution 🎶. The Sender doesn't have to wait for a Measurement-Response packet to arrive before sending the next Measurement-Request packet. In lots of cases, waiting just isn't possible if you want to keep that inter-packet distribution 🏃♀️.
The default format for all timestamps is the one in RFC 5905 [RFC5905] ⏰.
Last but not least, all messages and the fields inside them are assumed to be in network order 🌐. All data fields are unsigned, unless it says otherwise 🔢.
5. Extensions ✨
okay so this section is about how the protocol can grow new powers 🧚 like brand new kinds of measurements, and it's giving future-proof.
To make room for new types of measurements, you can define extra Measurement-Type CSLDs to ride inside the Control-Request and Control-Response messages, swapping them in for the UDP-Measurement CSLD defined in this doc 🦋. The meaning and precise format of one of these CSLDs needs to be defined in a separate specification. That spec also needs to describe the right formats for the messages in the Measurement Phase 💅.
The protocol can also be extended by adding support for new values to the registries defined in this document 🌈.
6. IANA Considerations 🎀
The registries below are needed for the protocol to be extensible 🍓. In the registries, the terms 'Private Use' and 'Experimental Use' have the same meaning as described in RFC 5226 [RFC5226].
For the following registries, the ranges designated "Unassigned" are governed by the policy 'RFC Required' as described in RFC 5226 [RFC5226].
Cisco SLA Protocol Version Number Registry
+-----------+------------------------+
| Version | Description |
+-----------+------------------------+
| 0 | Reserved |
| 1 | Reserved |
| 2 | Version 2 |
| 3 - 200 | Unassigned |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+-----------+------------------------+The version number should be changed only when the structure of the Command messages is different from the basic Command-Header and CSLD structure described in this document 👑.
Cisco SLA Protocol CSLD Command Registry
+---------------+--------------------------+
| CSLD Type | Description |
+---------------+--------------------------+
| 0 | Reserved |
| 1 | Authentication CSLD |
| 2 | UDP-Measurement |
| 3 - 52 | Reserved |
| 53 - 10239 | Unassigned |
| 10240 - 20479 | Private Use |
| 20480 - 65535 | Experimental Use |
+---------------+--------------------------+It is envisioned that future documents will provide their own Measurement-Type number and format of the Data portion 🔮.
Cisco SLA Protocol Authenticator Modes Registry
+-----------+--------------------------+
| Mode | Description |
+-----------+--------------------------+
| 0 | No Authentication |
| 1 | SHA256 |
| 2 | HMAC-SHA-256 |
| 3 - 200 | Unassigned |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+-----------+--------------------------+Cisco SLA Protocol Roles Registry
+-----------+--------------------------+
| Role | Description |
+-----------+--------------------------+
| 0 | Reserved |
| 1 | Sender |
| 2 | Responder |
| 3 - 200 | Unassigned |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+-----------+--------------------------+Cisco SLA Protocol Measurement Type Registry
+------------------+------------------------+
| Measurement Type | Description |
+------------------+------------------------+
| 0 | Reserved |
| 1 | Reserved |
| 2 | Reserved |
| 3 | UDP |
| 4 - 52 | Reserved |
| 53-10239 | Unassigned |
| 10240 - 20479 | Private Use |
| 20480 - 65535 | Experimental Use |
+------------------+------------------------+The following registry is also needed for the extensibility of the protocol 🧩. However, the range designated "Unassigned" is governed by the policy 'First Come First Served' as described in RFC 5226 [RFC5226].
Cisco SLA Protocol Status Types Registry
+-----------+-------------------------------------------------------+
| Status | Description |
+-----------+-------------------------------------------------------+
| 0 | Success |
| --------- | -------------------------- |
| 1 | Fail - catch all |
| --------- | -------------------------- |
| 2 | Authentication failure |
| --------- | -------------------------- |
| 3 | Format error - sent when any CSLD type is not |
| | recognized or any part of a CSLD has a value that is |
| | not recognized |
| --------- | -------------------------- |
| 4 | Port in use - the UDP/TCP port is already being used |
| | by some other application and cannot be reserved |
| --------- | -------------------------- |
| 5 - 40959 | Unassigned |
| --------- | -------------------------- |
| 40960 - | Experimental Use |
| 65535 | |
+-----------+-------------------------------------------------------+Finally, the following registry is also needed for the extensibility of the protocol 🫶. However, the range designated "Unassigned" is governed by the policy 'Specification Required' as described in RFC 5226 [RFC5226].
Cisco SLA Protocol Address Family Registry
+--------------+------------------------+
| Address Type | Description |
+--------------+------------------------+
| 0 | Reserved |
| 1 | Reserved |
| 2 | IPv4 |
| 3 | IPv6 |
| 4 - 200 | Unassigned |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+--------------+------------------------+7. Security Considerations 💀
Okay this part is serious, bestie, so pay attention 😭.
7.1. Message Authentication
When the mode for the Authentication CSLD is set to 1, the Message Authentication Digest is generated using the SHA256 algorithm and is to be calculated over the entire packet including the Message Authentication Digest field, which MUST be set to all 0s 🔐.
When the mode for the Authentication CSLD is set to 2, the Message Authentication Digest is generated using the HMAC-SHA-256 algorithm as described in RFC 4868 [RFC4868] and is to be calculated over the entire packet including the Message Authentication Digest field, which MUST be set to all 0s 🔐.
When the mode field is set to 0, the Random Number and the Message Authentication Digest fields MAY be included; when present, they MUST be set to all 0s 🙈.
7.2. IPsec Considerations
It is RECOMMENDED that IPsec be employed to afford better security 🛡️. IPsec provides enhanced privacy as well as an automated key-distribution mechanism ✨. The recommendations below are similar to those in Section 2 of RFC 3579 [RFC3579].
7.2.1. Control Traffic
For Senders implementing this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 1167". This causes the Sender to initiate IPsec when sending control traffic to any Responder 🚀. If some Responders contacted by the Sender do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-Responder, destination port UDP 1167".
For Responders implementing this specification, the IPsec policy would be "Require IPsec, from any to me, destination port UDP 1167". This causes the Responder to require use of IPsec 🔒. If some Sender does not support IPsec, then a more granular policy will be required: "Require IPsec, from IPsec-Capable-Sender to me".
7.2.2. Measurement Traffic
As the Control Phase occurs before the Measurement Phase, it should be possible to build an IPsec Security Association once a successful Control-Response is received 🧠.
For Senders implementing this specification, the IPsec policy would be "Initiate IPsec, from me to negotiated address, destination is negotiated port". This causes the Sender to initiate IPsec when sending measurement traffic to the Responder 📡. If some Responders contacted by the Sender do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-Responder, destination is negotiated port".
For Responders implementing this specification, the IPsec policy would be "Require IPsec, from negotiated address to me, destination is negotiated port". This causes the Responder to require use of IPsec 🔐. If some Sender does not support IPsec, then a more granular policy will be required: "Require IPsec, from IPsec-Capable-Sender to me, destination is negotiated port".
7.3. Replay Protection
For the Control messages, the originator of the message MAY choose to include a current value in the Sent Timestamp field indicating the time the message was submitted for transmission; otherwise, it MUST be set to 0 ⏰. The receiver of the message MAY choose to validate it if the timestamp is within an acceptable range. The measurement traffic described in this document contains a timestamp to indicate the sent time and hence no new field is required 💖.
8. Acknowledgements 💜
The authors wish to acknowledge the contributions of several key people who contributed to the current form of the document: Hanlin Fang, David Wang, Anantha Ramaiah, Max Pritikin, Malini Vijayamohan, and Susan Boyle 🫶🌸.
9. References 🌸
9.1. Normative References 🦋
[IEEE1588] IEEE, "1588-2008 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.9.2. Informative References 📚
okay so these are the informative ones, bestie 🧚. they aren't required reading, but they give you the backstory on the stuff this doc leans on. the full details are right here:
[RFC3579]Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. 🔐[RFC4656]Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. 🦋[RFC5357]Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. 💜[RFC6374]Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. 🌈
Authors' Addresses ✨
and here's the squad that wrote this one! 👑 they're all at Cisco Systems, so the contact details are the same across the board, but each person has their own email. the full blocks are below so you can reach out 💅
Murtaza S. Chiba 🌸
Murtaza S. Chiba
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: mchiba@cisco.comAlexander Clemm 🍓
Alexander Clemm
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: alex@cisco.comSteven Medley 🎀
Steven Medley
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: stmedley@cisco.comJoseph Salowey 🫶
Joseph Salowey
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: jsalowey@cisco.comSudhir Thombare ⭐
Sudhir Thombare
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: thombare@cisco.comEshwar Yedavalli 🦋
Eshwar Yedavalli
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
EMail: eshwar@cisco.comand that's the whole spec, bestie! 🌈 six authors, one very slay document 💖
📦 where this page comes from
- ietf: rfc6812 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms