Cisco Service-Level Assurance Protocol
draft-cisco-sla-protocol-04
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6812.
|
|
|---|---|---|---|
| Authors | Murtaza Chiba , Alexander Clemm , Steven Medley , Joseph A. Salowey , Sudhir Thombare , Eshwar Yedavalli | ||
| Last updated | 2015-10-14 (Latest revision 2012-10-19) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| IETF conflict review | conflict-review-cisco-sla-protocol | ||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6812 (Informational) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Wesley Eddy | ||
| Send notices to | rfc-ise@rfc-editor.org |
draft-cisco-sla-protocol-04
Internet-Draft Cisco SLA Protocol October 2012
5. IANA Considerations
The following registries are needed for the extensibility of the
protocol and the terms 'Private Use' and 'Experimental Use' found in
the registries in this section have the same meaning as described in
RFC 5226 [RFC5226].
Furthermore, for the following registries, the ranges designated
"Available for future extensions" will be governed by the policy 'RFC
Required' as described in RFC 5226 [RFC5226].
Cisco Service Level Assurance Protocol - Version Number Registry
+-----------+---------------------------------+
| Version | Description |
+-----------+---------------------------------+
| 0 | Reserved |
| 1 | Reserved |
| 2 | Version 2 |
| 3 - 200 | Available for future extensions |
| 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 Service Level Assurance Protocol - CSLD Command Registry
+---------------+---------------------------------+
| CSLD Type | Description |
+---------------+---------------------------------+
| 0 | Reserved |
| 1 | Authentication CSLD |
| 2 | UDP Measurements |
| 3 - 52 | Reserved |
| 53 - 10239 | Available for future extensions |
| 10240 - 20479 | Private Use |
| 20480 - 65535 | Experimental Use |
+---------------+---------------------------------+
It is envisioned that future documents will provide their own
measurement type number along with the format of the Data portion.
Cisco Service Level Assurance Protocol - Authenticator Modes Registry
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 21]
Internet-Draft Cisco SLA Protocol October 2012
+-----------+---------------------------------+
| Mode | Description |
+-----------+---------------------------------+
| 0 | No Authentication |
| 1 | SHA256 |
| 2 | HMAC-SHA-256 |
| 3 - 200 | Available for future extensions |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+-----------+---------------------------------+
Cisco Service Level Assurance Protocol - Roles Registry
+-----------+---------------------------------+
| Role | Description |
+-----------+---------------------------------+
| 0 | Reserved |
| 1 | Sender |
| 2 | Responder |
| 3 - 200 | Available for future extensions |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+-----------+---------------------------------+
Cisco Service Level Assurance Protocol - Measurement Type Registry
+------------------+---------------------------------+
| Measurement Type | Description |
+------------------+---------------------------------+
| 0 | Reserved |
| 1 | Reserved |
| 2 | Reserved |
| 3 | UDP |
| 4 - 52 | Reserved |
| 53-10239 | Available for future extensions |
| 10240 - 20479 | Private Use |
| 20480 - 65535 | Experimental Use |
+------------------+---------------------------------+
The following registry is also needed for the extensibility of the
protocol, however, the range designated "Available for future
extensions" will be governed by the policy 'First Come First Served'
as described in RFC 5226 [RFC5226]
Cisco Service Level Assurance Protocol - Status Types Registry
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 22]
Internet-Draft Cisco SLA Protocol October 2012
+-----------+-------------------------------------------------------+
| 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 | Available for future extensions |
| --------- | -------------------------- |
| 40960 - | Experimental Use |
| 65535 | |
+-----------+-------------------------------------------------------+
Finally, the following registry is also needed for the extensibility
of the protocol, however, the range designated "Available for future
extensions" will be governed by the policy 'Specification Required'
as described in RFC 5226 [RFC5226]
Cisco Service Level Assurance Protocol - Address Family Registry
+--------------+---------------------------------+
| Address Type | Description |
+--------------+---------------------------------+
| 0 | Reserved |
| 1 | IPv4 |
| 2 | IPv6 |
| 3 - 200 | Available for future extensions |
| 201 - 225 | Private Use |
| 226 - 255 | Experimental Use |
+--------------+---------------------------------+
6. Security Considerations
6.1. Message Authentication
When the mode for the Authentication CSLD is set to 1, the Message
Authentication Digest is generated using the SHA 256 algorithm and is
to be calculated over the entire packet including the Message
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 23]
Internet-Draft Cisco SLA Protocol October 2012
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 as
described in RFC 4868 [RFC4868]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 field is set to 0, the Random Number field and the
Message Authentication Digest MUST both be set to all 0s.
6.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 following recommendations are similar to
RFC3579, Section 2 [RFC3579]
6.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".
6.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".
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 24]
Internet-Draft Cisco SLA Protocol October 2012
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".
6.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, it MUST be set to 0
otherwise. The receiver of the message MAY choose to validate 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.
7. Terminology
+-------------+-----------------------------------------------------+
| Term | Description |
+-------------+-----------------------------------------------------+
| Control | A phase during which Control Request and Control |
| Phase | Response is 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/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 |
| --------- | -------------------------- |
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 25]
Internet-Draft Cisco SLA Protocol October 2012
| UDP | User Datagram Protocol |
+-------------+-----------------------------------------------------+
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, and Malini
Vijayamohan.
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., 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.
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 26]
Internet-Draft Cisco SLA Protocol October 2012
[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
Fax:
Email: mchiba@cisco.com
URI:
Alexander Clemm
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
Fax:
Email: alex@cisco.com
URI:
Steven Medley
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
Fax:
Email: stmedley@cisco.com
URI:
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 27]
Internet-Draft Cisco SLA Protocol October 2012
Joseph Salowey
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
Fax:
Email: jsalowey@cisco.com
URI:
Sudhir Thombare
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
Fax:
Email: thombare@cisco.com
URI:
Eshwar Yedavalli
Cisco Systems
170 West Tasman Drive
San Jose, 95134
USA
Phone: 1-408-526-4000
Fax:
Email: eshwar@cisco.com
URI:
Murtaza S. Chiba, et al. Expires April 22, 2013 [Page 28]