< draft-lear-opsawg-mud-bw-profile-00.txt   draft-lear-opsawg-mud-bw-profile-01.txt >
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft J. Henry Internet-Draft J. Henry
Intended status: Experimental Cisco Systems Intended status: Experimental Cisco Systems
Expires: April 23, 2019 October 20, 2018 Expires: January 9, 2020 July 08, 2019
Network QoS Expectations Extensions for MUD Bandwidth Profiling Extensions for MUD
draft-lear-opsawg-mud-bw-profile-00 draft-lear-opsawg-mud-bw-profile-01
Abstract Abstract
Manufacturer Usage Descriptions (MUD) are a means by which devices Manufacturer Usage Descriptions (MUD) are a means by which devices
can establish expectations about how they are intended to behave, and can establish expectations about how they are intended to behave, and
how the network should treat them. Earlier work focused on access how the network should treat them. Earlier work focused on access
control. This draft specifies a means by which manufacturers can control. This draft specifies a means by which manufacturers can
express to deployments what form of bandwidth profile devices are express to deployments what form of bandwidth profile devices are
expected to have with respect to specific services. expected to have with respect to specific services.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2.1. The mud-qos YANG model . . . . . . . . . . . . . . . . . 4 2.1. The mud-qos YANG model . . . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.1. Manufacturer Attempts to Exhaust Available Bandwidth . . 7 4.1. Manufacturer Attempts to Exhaust Available Bandwidth . . 7
4.2. Device lies about what it is to get more bandwidth . . . 8 4.2. Device lies about what it is to get more bandwidth . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 8 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Devices connecting to networks will often exhibit certain nominal Devices connecting to networks will often exhibit certain nominal
behaviors that can be described. In addition, sometimes device behaviors that can be described. In addition, sometimes device
require particular network behaviors such as appropriate quality-of- require particular network behaviors such as appropriate quality-of-
service treatment. Manufacturer Usage Descriptions service treatment. Manufacturer Usage Descriptions [RFC8520] discuss
[I-D.ietf-opsawg-mud] discuss how to characterize access control how to characterize access control requirements, for instance. As
requirements, for instance. As just mentioned, access control just mentioned, access control requirements are not the only
requirements are not the only requirements device manufacturers may requirements device manufacturers may wish to specify. This memo
wish to specify. This memo defines an extension to the MUD YANG defines an extension to the MUD YANG model by which manufacturers can
model by which manufacturers can characterize the traffic exchanged characterize the traffic exchanged with a Thing, and specify how much
with a Thing, and specify how much bandwidth is required by a device bandwidth is required by a device or may be expected of a device over
or may be expected of a device over some period of time for each some period of time for each given service it uses.
given service it uses.
Network deployments may use this information in two ways: Network deployments may use this information in two ways:
o Provisioning of bandwidth based on device requirements; o Provisioning of bandwidth based on device requirements;
o Facilitating proper traffic characterization and marking by the o Facilitating proper traffic characterization and marking by the
network infrastructure network infrastructure
o Policing of devices to not permit them to exceed design o Policing of devices to not permit them to exceed design
requirements. In particular, a device that is transmitting a DSCP requirements. In particular, a device that is transmitting a DSCP
skipping to change at page 4, line 42 skipping to change at page 4, line 42
+--rw service* [name] +--rw service* [name]
+--rw name string +--rw name string
+--rw timeframe uint32 +--rw timeframe uint32
+--rw pps? uint32 +--rw pps? uint32
+--rw bps? uint64 +--rw bps? uint64
+--rw dscp? inet:dscp +--rw dscp? inet:dscp
+--rw aclname? -> /acl:acls/acl/name +--rw aclname? -> /acl:acls/acl/name
2.1. The mud-qos YANG model 2.1. The mud-qos YANG model
<CODE BEGINS>file "ietf-mud-bw-profile@2018-10-20.yang" <CODE BEGINS>file "ietf-mud-bw-profile@2019-07-08.yang"
module ietf-mud-bw-profile { module ietf-mud-bw-profile {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-bw-profile"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-bw-profile";
prefix mud-qos; prefix mud-qos;
import ietf-access-control-list { import ietf-access-control-list {
prefix acl; prefix acl;
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-mud { import ietf-mud {
prefix mud; prefix mud;
} }
organization organization
"IETF OPSAWG (Ops Area) Working Group"; "IETF OPSAWG (Ops Area) Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/opsawg/ "WG Web: http://tools.ietf.org/wg/opsawg/
WG List: opsawg@ietf.org WG List: opsawg@ietf.org
Author: Eliot Lear Author: Eliot Lear
lear@cisco.com lear@cisco.com
Author: Jerome Henry Author: Jerome Henry
jerhenry@cisco.com jerhenry@cisco.com
"; ";
description description
"This YANG module augments the ietf-mud model to provide the "This YANG module augments the ietf-mud model to provide the
network with some understanding as to the QoS requirements and network with some understanding as to the QoS requirements and
anticipated behavior of a device. anticipated behavior of a device.
The to-device-policy and from-device-policy containers are The to-device-policy and from-device-policy containers are
augmented with one additional container, which expresses how many augmented with one additional container, which expresses how many
packets per second a device is expected to transmit, how much packets per second a device is expected to transmit, how much
bandwidth it is expected to use, and what QoS is required, and bandwidth it is expected to use, and what QoS is required, and
how much bandwidth is to be expected to be prioritized. An how much bandwidth is to be expected to be prioritized. An
access-list is further specified to indicate how QoS should be access-list is further specified to indicate how QoS should be
marked on ingress and egress. marked on ingress and egress.
Copyright (c) 2016,2017,2018 IETF Trust and the persons Copyright (c) 2016,2017,2018 IETF Trust and the persons
identified as the document authors. All rights reserved. identified as the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-10-20 { revision 2019-07-08 {
description description
"Initial proposed standard."; "Initial proposed standard.";
reference "RFC XXXX: QoS for MUD Specification"; reference "RFC XXXX: Bandwidth Descriptions for MUD Specification";
} }
grouping mud-qos-params { grouping mud-bw-params {
description description
"QoS and Bandwidth additions for MUD"; "QoS and Bandwidth additions for MUD";
container bw-params { container bw-params {
description description
"Expected Bandwidth to/from device"; "Expected Bandwidth to/from device";
list service { list service {
key "name"; key "name";
description description
"a list of services that are being described."; "a list of services that are being described.";
leaf name { leaf name {
type string; type string;
description description
"Service Name"; "Service Name";
} }
leaf timeframe { leaf timeframe {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"the period of time in seconds one "the period of time in seconds one
expects a service to burst at described rates"; expects a service to burst at described rates";
} }
leaf pps { leaf pps {
type uint32; type uint32;
description description
"number of packets per second to be expected."; "number of packets per second to be expected.";
} }
leaf bps { leaf bps {
type uint64; type uint64;
description description
"number of bits per second to be expected."; "number of bits per second to be expected.";
} }
leaf dscp { leaf dscp {
type inet:dscp; type inet:dscp;
description description
"The DSCP that packets for this service should "The DSCP that packets for this service should
treated with. N.B., just because the manufacturer treated with. N.B., just because the manufacturer
wants this, doesn't mean it will get it. However, wants this, doesn't mean it will get it. However,
manufacturers who do set the DSCP value in their manufacturers who do set the DSCP value in their
packets SHOULD indicate that in this description. packets SHOULD indicate that in this description.
This field differs from the dscp field in the matches This field differs from the dscp field in the matches
portion of the access-list in that here the field is portion of the access-list in that here the field is
populated when the manufacturer states what the nominal populated when the manufacturer states what the nominal
value of the DSCP field MAY be, and how much bandwidth value of the DSCP field MAY be, and how much bandwidth
can be used when it is set. Note that it is possible can be used when it is set. Note that it is possible
that the same service may use multiple DSCP values, that the same service may use multiple DSCP values,
depending on the circumstances. In this case, service depending on the circumstances. In this case, service
entry MUST be made."; entry MUST be made.";
} }
leaf aclname { leaf aclname {
type leafref { type leafref {
path "/acl:acls/acl:acl/acl:name"; path "/acl:acls/acl:acl/acl:name";
} }
description description
"The name of the ACL that will match packets "The name of the ACL that will match packets
for a given service."; for a given service.";
} }
} }
} }
} }
augment "/mud:mud/mud:to-device-policy" { augment "/mud:mud/mud:to-device-policy" {
description description
"add inbound QoS parameters"; "add inbound QoS parameters";
uses mud-qos-params; uses mud-bw-params;
} }
augment "/mud:mud/mud:from-device-policy" { augment "/mud:mud/mud:from-device-policy" {
description description
"add outbound QoS parameters"; "add outbound QoS parameters";
uses mud-qos-params; uses mud-bw-params;
} }
} }
<CODE ENDS> <CODE ENDS>
3. Examples 3. Examples
TBD TBD
4. Security Considerations 4. Security Considerations
4.1. Manufacturer Attempts to Exhaust Available Bandwidth 4.1. Manufacturer Attempts to Exhaust Available Bandwidth
An attacking manufacturer claims a device would require substantial An attacking manufacturer claims a device would require substantial
skipping to change at page 8, line 26 skipping to change at page 8, line 26
The IANA is requested to add "qos" to the MUD extensions registry as The IANA is requested to add "qos" to the MUD extensions registry as
follows: follows:
Extension Name: MUD Extension Name: MUD
Standard reference: This document Standard reference: This document
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-opsawg-mud] [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520,
Description Specification", draft-ietf-opsawg-mud-25 (work DOI 10.17487/RFC8520, March 2019,
in progress), June 2018. <https://www.rfc-editor.org/info/rfc8520>.
6.2. Informative References 6.2. Informative References
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX) "Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77, Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>. <https://www.rfc-editor.org/info/rfc7011>.
Appendix A. Changes from Earlier Versions Appendix A. Changes from Earlier Versions
Draft -01:
o Very modest changes.
Draft -00: Draft -00:
o Initial revision o Initial revision
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
Richtistrasse 7 Richtistrasse 7
Wallisellen CH-8304 Wallisellen CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Jerome Henry Jerome Henry
 End of changes. 20 change blocks. 
141 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/