doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc6812.txt b/doc/rfc/rfc6812.txt
new file mode 100644
index 0000000..1fcd208
--- /dev/null
+++ b/doc/rfc/rfc6812.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Independent Submission                                          M. Chiba
+Request for Comments: 6812                                      A. Clemm
+Category: Informational                                        S. Medley
+ISSN: 2070-1721                                               J. Salowey
+                                                             S. Thombare
+                                                            E. Yedavalli
+                                                           Cisco Systems
+                                                            January 2013
+
+
+                 Cisco Service-Level Assurance Protocol
+
+Abstract
+
+   Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a
+   Performance Measurement protocol that has been widely deployed.  The
+   protocol is used to measure service-level parameters such as network
+   latency, delay variation, and packet/frame loss.  This document
+   describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to
+   enable vendor interoperability.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   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 document 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 date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+Chiba, et al.                 Informational                     [Page 1]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+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 . . . . . . . . . . . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 2]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+1.  Introduction
+
+   Active network performance measurements are becoming critical data
+   points for administrators monitoring the health of the network.  As
+   service providers look to differentiate their offerings, performance
+   measurement is increasingly becoming an important tool to monitor
+   service-level guarantees and, in general, to monitor the health of a
+   network.
+
+   Performance metrics, both one-way and two-way, can be used for pre-
+   deployment validation as well as for measuring in-band live network-
+   performance characteristics.  It can be used to measure service
+   levels in L2 and L3 networks as well as for applications running on
+   top of L3.  Active performance measurements are gathered by analyzing
+   synthetically generated request and response packets or frames.  This
+   is in contrast to passive measurements that analyze live traffic
+   flowing through a particular network element.
+
+   There is a growing body of work on Performance Measurement standards
+   that enable interoperability between different vendors' network
+   elements by describing common measurement protocols as well as
+   metrics.  The IETF has actively developed Standards Track documents
+   on the subject, such as "A One-way Active Measurement Protocol
+   (OWAMP)" [RFC4656] and "Two-Way Active Measurement Protocol (TWAMP)"
+   [RFC5357].
+
+   Cisco's SLA Protocol is another example of a Performance Measurement
+   protocol that offers a rich set of measurement message types.  The
+   measurement types can be classified as those that test connectivity
+   (ping like) by providing round-trip or one-way latency measures, and
+   those that provide a richer set of statistics including network
+   jitter and packet or frame loss.  Each type of active measurement
+   exchange mimics an actual protocol exchange.
+
+   Cisco's SLA Protocol UDP-Measurement message exchanges, as covered in
+   this document to enable interoperability, simulate a UDP application
+   and can be used to simulate either Voice or Video traffic that is
+   encoded in RTP frames within UDP envelopes.  The Measurement-Type
+   UDP-Measurement message exchanges carry information that provide the
+   ability to derive a robust set of statistics.
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 3]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   +-------------+-----------------------------------------------------+
+   | 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 consists of two distinct phases: the Control
+   Phase and the Measurement Phase.  Each phase is comprised of
+   information 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 forms
+   the base protocol.  This phase establishes the identity of the Sender
+   and provides information for the Measurement Phase.  A single message
+   pair of Control-Request and Control-Response marks this phase.  The
+
+
+
+Chiba, et al.                 Informational                     [Page 4]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   Sender initiates a Control-Request message that is acknowledged by
+   the Responder with a Control-Response message.  The Control-Request
+   may be sent multiple times if a Control-Response has not been
+   received; the number of times the message is retried is configurable
+   on the Sender element.
+
+   The Measurement Phase forms the second phase and is comprised of a
+   sequence of Measurement-Request and Measurement-Response messages.
+   These messages may be exchanged as often as required.  Each
+   Measurement-Request message is acknowledged by the Responder with a
+   Measurement-Response message.
+
+   The number and frequency with which messages are sent SHOULD be
+   controlled by configuration on the Sender element, along with the
+   waiting time for a Control-Response.
+
+   The following sequence diagram depicts the message exchanges:
+
+       +-+-+-+-+-+-+-+      Control-Request           +-+-+-+-+-+-+-+
+       |             |                                |             |
+       |    Sender   |                                |  Responder  |
+       |             |                                |             |
+       |             |                                |             |
+       +-+-+-+-+-+-+-+                                +-+-+-+-+-+-+-+
+              |                                              |
+              |             Control-Request                  |
+              | -------------------------------------------->|
+              |                                              |
+              |             Control-Response                 |
+              |<---------------------------------------------|
+              |                                              |
+              |                                              |
+              |             Measurement-Request(1)           |
+              | -------------------------------------------->|
+              |                                              |
+              |             Measurement-Response(1)          |
+              |<---------------------------------------------|
+              |                                              |
+              .                                              .
+              .                                              .
+              .                                              .
+              .                                              .
+              .             Measurement-Request(n)           .
+              | -------------------------------------------->|
+              |                                              |
+              |             Measurement-Response(n)          |
+              |<---------------------------------------------|
+              |                                              |
+
+
+
+Chiba, et al.                 Informational                     [Page 5]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+3.1.  Control Phase
+
+   The Control Phase begins with the Sender sending a Control-Request
+   message to the Responder.  The Control-Request message is sent to UDP
+   port 1167 on the Responder requesting that a Measurement Phase UDP
+   port be opened and, in addition, indicates the duration for which the
+   port needs to remain open.  The Responder replies by sending a
+   Control-Response with an appropriate Status indicating Success when
+   the Sender identity is verified and the requested UDP port was
+   successfully opened.  In all other cases, a non-zero Status is
+   returned in the Command-Header Status field.
+
+   The sequence of exchanges is as indicated in the following diagram:
+
+       +-+-+-+-+-+-+-+      Control-Request           +-+-+-+-+-+-+-+
+       |             |------------------------------->|             |
+       |    Sender   |                                |  Responder  |
+       |             |      Control-Response          |             |
+       |             |<-------------------------------|             |
+       +-+-+-+-+-+-+-+                                +-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 6]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+3.1.1.  Control-Request Message
+
+   The Control-Request message consists of a Command-Header followed by
+   one or more Command, Status, Length and Data sections (henceforth
+   known as CSLD).  At a minimum, there SHOULD be two CSLD sections, one
+   of which is the authentication CSLD section and the other carries
+   information 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                                 .
+       .                                                               .
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 7]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+3.1.1.1.  Command-Header
+
+   The Command-Header is the first section of the Control-Request
+   message and is depicted below:
+
+        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                         |
+       +                                                               +
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Command-Header fields hold the following meaning:
+
+   +-----------+-----------+-------------------------------------------+
+   | 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.              |
+   | --------- | --------- | --------------------------                |
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 8]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   | --------- | --------- | --------------------------                |
+   | 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 new number for each new
+   request and is monotonically increasing.  When the Control-Request is
+   to be retried, the sequence number MUST remain unchanged.
+
+3.1.1.2.  CSLDs
+
+   The ordered list of the two CSLDs to be included along with the
+   Command-Header are:
+
+   o  The Authentication CSLD
+
+   o  A Measurement-Type CSLD
+
+   In this revision of the protocol, only a single Measurement-Type CSLD
+   has been defined, the UDP-Measurement CSLD.  For future extensions,
+   it is possible to add more Measurement-Type CSLDs.  For more details,
+   see Section 5 on extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                     [Page 9]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+3.1.1.2.1.  Authentication CSLD
+
+   The Authentication CSLD provides message authentication and verifies
+   that the requester knows the shared secret.  The following is the
+   format for the Authentication CSLD:
+
+       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                .
+      .                                                               .
+      .                                                               .
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 10]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   The fields for the Authentication CSLD have the following meaning:
+
+   +----------------+-----------+--------------------------------------+
+   | 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.                 |
+   +----------------+-----------+--------------------------------------+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 11]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+3.1.1.2.2.  UDP-Measurement CSLD
+
+   The UDP-Measurement CSLD indicates the Measurement-Type to be used
+   during the Measurement Phase and specifies the addresses and UDP port
+   to be opened as well as the duration that the port has to be kept
+   open for the Measurement Phase.  The format of the CSLD is as
+   follows:
+
+       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                   |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 12]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                                                               +
+      |                  Measurement Destination Address              |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Control Source Port          |          Reserved             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Measurement Source Port      | Measurement Destination Port  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Duration                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Note: Duration is specified in milliseconds.
+
+   The fields in the UDP-Measurement CSLD have the following meaning:
+
+   +-------------+-----------+-----------------------------------------+
+   | 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.          |
+   | ---------   | --------- | --------------------------              |
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 13]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   | ---------   | --------- | --------------------------              |
+   | 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.                           |
+   | ---------   | --------- | --------------------------              |
+
+
+
+
+Chiba, et al.                 Informational                    [Page 14]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   | ---------   | --------- | --------------------------              |
+   | 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.               |
+   +-------------+-----------+-----------------------------------------+
+
+   Note: The source addresses are only indicative of identity of the
+   originator and cannot be used as a destination address for responses
+   in a NAT environment.
+
+3.1.2.  Control-Response Message
+
+   In response to the Control-Request message, the network element
+   designated the Responder sends back a Control-Response message that
+   reflects the Command-Header with an updated Status field and includes
+   the two CSLD sections that also carry updated Status fields.  Hence,
+   the format is identical to the Control-Request message as described
+   above.
+
+   The following table shows the supported values of the Status fields:
+
+   +-----------+-------------------------------------------------------+
+   | 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).                   |
+   +-----------+-------------------------------------------------------+
+
+   The Status field values are applicable to both Command-Header and
+   CSLD sections.  In a Command-Header, the Status field indicates
+   Success only if all the CSLD sections have their Status set to
+
+
+
+Chiba, et al.                 Informational                    [Page 15]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   Success.  The Command-Header Status field is set to non-zero
+   otherwise.  The Status field in a Command-Header SHOULD only make use
+   of status values 0 through 3, whereas CSLDs can also make use of
+   other status values as applicable.  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
+   and the Message Authentication Digest in the Authentication CSLD.
+   The Message Authentication Digest is computed in the same way as the
+   Control-Request message.  The Random Number field MUST be reflected
+   without modification.  The Session Identifier MAY be updated to
+   reflect a locally significant unique value; it MUST be 0 if not
+   specified.
+
+3.2.  Measurement Phase
+
+   Upon receiving the Control-Response message with the Status set to
+   Success, the second phase of the protocol, the Measurement Phase, is
+   initiated.  In all other cases when the Status is not set to Success,
+   no measurement traffic is initiated.  In the Measurement Phase, the
+   Sender sends a stream of measurement messages.  The measurement
+   message stream consists of packets or frames that are spaced a
+   configured number of milliseconds apart.
+
+      +-+-+-+-+-+-+-+      Measurement-Request(n)    +-+-+-+-+-+-+-+
+      |             |------------------------------->|             |
+      |    Sender   |                                |  Responder  |
+      |             |      Measurement-Response(n)   |             |
+      |             |<-------------------------------|             |
+      +-+-+-+-+-+-+-+                                +-+-+-+-+-+-+-+
+
+   The format of the measurement messages as defined by this document
+   for UDP-Measurements is as shown below and is the same for the
+   exchange in both directions.  That is, the format is the same when
+   sent from the Sender to the Responder and when sent back from the
+   Responder to the Sender with the only difference being the update of
+   those fields that are designated with the Responder prefix; all other
+   fields MUST remain unchanged.
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 16]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+       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                                 .
+      .                                                               .
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 17]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   The fields for the UDP-Measurement Measurement-Request have the
+   following meaning:
+
+   +-------------+-----------+-----------------------------------------+
+   | 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.                            |
+   | ---------   | --------- | --------------------------              |
+
+
+
+
+Chiba, et al.                 Informational                    [Page 18]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   | ---------   | --------- | --------------------------              |
+   | 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] and is as follows: the first 32 bits represent the unsigned
+   integer number of seconds elapsed since 0 h on 1 January 1900; the
+   next 32 bits represent the fractional part of a second thereof.  The
+   timestamp definition is also similar to that described in RFC 4656
+   [RFC4656].
+
+   In addition, the timestamp format used can be as described for the
+   low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time
+   Protocol timestamp format [IEEE1588].  This truncated format consists
+   of a 32-bit seconds field followed by a 32-bit nanoseconds field, and
+   is the same as the IEEE 1588v1 timestamp format.  This timestamp
+   definition is similar to the default timestamp specified in RFC 6374
+   [RFC6374]
+
+   Implementations MUST use only one of the two formats.  The chosen
+   format is negotiated out-of-band between the endpoints or defaults to
+   the format as defined in RFC 5905. [RFC5905]
+
+4.  Implementation Notes
+
+   Responder implementations SHOULD support simultaneous measurements
+   destined to a single port either from the same or a different Sender.
+   For different measurement instances that originate from the same
+   Sender, there MUST be a clear method for the Responder to distinguish
+   the traffic, for example, per a unique 5-tuple of protocol, source
+   address, source port, destination address, and destination port.
+
+   A Control-Request that is received for the same Measurement-Type
+   request as identified by the 5-tuples, for instance, SHOULD result in
+   the resetting of the duration timer as well as the Responder sequence
+   number.
+
+   A Control Phase followed by the Measurement Phase can be repeated in
+   order to have a continuous measurement over the entire lifetime of a
+   device.
+
+
+
+Chiba, et al.                 Informational                    [Page 19]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   The Authentication CSLD MUST always be included.  The Random Number
+   field is used to prevent dictionary attacks and is to be set to a
+   random value in environments where security is a concern.
+
+   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'; when present,
+   they MUST be set to 0.  For the SHA256 authenticator mode, the shared
+   secret is prepended to the Control message and the authentication
+   algorithm is then run over the complete data including the shared
+   secret.  The SHA256 mode is included for ease of implementation, and
+   use of the HMAC variant is strongly recommended for stronger
+   security.
+
+   If the UDP port indicated in the UDP-Measurement CSLD is busy, the
+   Responder MAY suggest an alternative port, in which case the Status
+   of the UDP-Measurement CSLD MUST be set to Success.  The Sender MAY
+   set a value of 0 in the field, in which case the Responder MAY choose
+   to open a port and send that back along with the Status set to
+   Success.  It should be noted that this behavior has security
+   ramifications and the port needs to be chosen very carefully by the
+   Responder.
+
+   The measurement stream typically consists of packets or frames with a
+   periodic inter-packet distribution.  The Sender need not wait for a
+   Measurement-Response packet to arrive before sending another
+   Measurement-Request packet; in many cases, it will not be possible to
+   wait in order to maintain the desired inter-packet distribution.
+
+   The default format for all timestamps is as specified in RFC 5905
+   [RFC5905].
+
+   All messages and fields within a message are assumed to be in network
+   order.  In addition, all data fields are unsigned unless mentioned
+   otherwise.
+
+5.  Extensions
+
+   This section describes how the protocol can be extended to allow for
+   additional functionality, such as new types of measurements.
+
+   In order to allow for new types of measurements, additional
+   Measurement-Type CSLDs can be defined to be carried within the
+   Control-Request and Control-Response messages in place of the UDP-
+   Measurement CSLD defined in this document.  The meaning and precise
+   format of such a CSLD needs to be defined in a separate
+   specification.  Such a specification will also need to describe the
+   appropriate formats for the messages in the Measurement Phase.
+
+
+
+Chiba, et al.                 Informational                    [Page 20]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   In addition, the protocol can be extended by adding support for new
+   values to registries defined in this document.
+
+6.  IANA Considerations
+
+   The registries defined below are needed for the extensibility of the
+   protocol.  In the registries, the terms 'Private Use' and
+   'Experimental Use' have the same meaning as described in RFC 5226
+   [RFC5226].
+
+   Furthermore, 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.
+
+
+
+
+Chiba, et al.                 Informational                    [Page 21]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   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       |
+         +------------------+------------------------+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 22]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   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       |
+            +--------------+------------------------+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 23]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+7.  Security Considerations
+
+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.
+
+
+
+
+Chiba, et al.                 Informational                    [Page 24]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   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.
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 25]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   [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
+
+   [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
+
+   Murtaza S. Chiba
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: mchiba@cisco.com
+
+
+   Alexander Clemm
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: alex@cisco.com
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 26]
+
+RFC 6812         Cisco Service-Level Assurance Protocol     January 2013
+
+
+   Steven Medley
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: stmedley@cisco.com
+
+
+   Joseph Salowey
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: jsalowey@cisco.com
+
+
+   Sudhir Thombare
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: thombare@cisco.com
+
+
+   Eshwar Yedavalli
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose,   95134
+   USA
+
+   Phone: 1-408-526-4000
+   EMail: eshwar@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al.                 Informational                    [Page 27]
+