Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Definitions of Managed Objects for Frame Relay Service Level Definitions
RFC 3202

Document	Type	RFC - Proposed Standard (January 2002) Updated by RFC 9141 Was draft-ietf-frnetmib-frmrelay-service (frnetmib WG)
	Authors	Robert A. Steinberger , Orly Nicklass
	Last updated	2013-03-02
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt html pdf htmlized bibtex
	Additional resources	Mailing list discussion
IESG	Responsible AD	(None)
	Send notices to	(None)

Email authors Email WG IPR References Referenced by Search Lists

RFC 3202

ANIMA WG T. Eckert, Ed.
Internet-Draft Huawei
Intended status: Standards Track M. Behringer, Ed.
Expires: February 8, 2019
S. Bjarnason
Arbor Networks
August 07, 2018

An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-18

Abstract

Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management
and Control Plane should ideally be self-managing, and as independent
as possible of configuration. This document defines such a plane and
calls it the "Autonomic Control Plane", with the primary use as a
control plane for autonomic functions. It also serves as a "virtual
out-of-band channel" for Operations Administration and Management
(OAM) communications over a network that is secure and reliable even
when the network is not configured, or misconfigured.

RFC 3202 Frame Relay Service Level Defs MIB January 2002

--
-- This table is used to define the sample control parameters
-- of service level definitions on individual PVCs.

frsldSmplCtrlTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldSmplCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
sampling control table."
::= { frsldObjects 2 }

frsldSmplCtrlEntry OBJECT-TYPE
SYNTAX FrsldSmplCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions sample control table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP,
frsldSmplCtrlIdx }
::= { frsldSmplCtrlTable 1 }

FrsldSmplCtrlEntry ::=
SEQUENCE {
--
-- Index Control Variables
--
frsldSmplCtrlIdx Integer32,
frsldSmplCtrlStatus RowStatus,
--
-- Collection Control Variables
--
frsldSmplCtrlColPeriod Integer32,
frsldSmplCtrlBuckets Integer32,
frsldSmplCtrlBucketsGranted Integer32
}

frsldSmplCtrlIdx OBJECT-TYPE
SYNTAX Integer32 (1..256)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index for this row in the
sample control table."
::= { frsldSmplCtrlEntry 1 }

Steinberger & Nicklass Standards Track [Page 32]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldSmplCtrlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
&Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 8, 2019.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents

Eckert, et al. Expires February 8, 2019 [Page 1]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

(https://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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane (Informative) . . . 15
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15
3.2. Secure Bootstrap over a not configured Network . . . . . 15
3.3. Data-Plane Independent Permanent Reachability . . . . . . 16
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 19
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20
6.1.1. Certificate Domain Information Field . . . . . . . . 21
6.1.2. ACP domain membership check . . . . . . . . . . . . . 23
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 24
6.1.3.1. GRASP objective for EST server . . . . . . . . . 25
6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 26
6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 26
6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 27
6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 27
6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 29
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 29
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 30
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 33
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 34
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 35
6.7. Security Association protocols . . . . . . . . . . . . . 35
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 35
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 36
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 36
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 37
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 37
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 38
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 38
6.8.2. ACP as the Security and Transport substrate for GRASP 38
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 40
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 41
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 42
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 42

Eckert, et al. Expires February 8, 2019 [Page 2]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 43
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 44
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 46
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 47
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 48
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 49
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 49
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 49
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 50
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 51
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 52
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 52
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 52
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 53
6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 53
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 54
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 54
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 54
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 55
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 55
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 55
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 55
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 55
6.11.1.12. Administrative parameters . . . . . . . . . . . 56
6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 56
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 56
6.12. General ACP Considerations . . . . . . . . . . . . . . . 56
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 57
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 57
6.12.4. Multiple links between nodes . . . . . . . . . . . . 58
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 58
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 61
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 62
8. Support for Non-ACP Components (Normative) . . . . . . . . . 64
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 64
8.1.2. Software Components . . . . . . . . . . . . . . . . . 66
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 67
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 68
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 69
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 70
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 70
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 72

Eckert, et al. Expires February 8, 2019 [Page 3]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 72
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 72
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74
9.3. The Administrator View . . . . . . . . . . . . . . . . . 75
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82
10.2.3. Certificate renewal and limitations . . . . . . . . 83
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86
10.3.2.2. Fast state propagation and Diagnostics . . . . . 87
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92
11. Security Considerations . . . . . . . . . . . . . . . . . . . 92
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104

Eckert, et al. Expires February 8, 2019 [Page 4]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 116
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116
15.1. Normative References . . . . . . . . . . . . . . . . . . 116
15.2. Informative References . . . . . . . . . . . . . . . . . 118
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Appendix A. Background and Futures (Informative) . . . . . . . . 123
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 123
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 125
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 125
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 126
A.5. ACP Information Distribution and multicast . . . . . . . 128
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132
A.9. Adopting ACP concepts for other environments . . . . . . 133
A.10. Further options / futures . . . . . . . . . . . . . . . . 134
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 134
A.10.2. More options for avoiding IPv6 Data-Plane dependency 135
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 135
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 136
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138

1. Introduction (Informative)

Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model].

Autonomic functions need an autonomically built communications
infrastructure. This infrastructure needs to be secure, resilient
and re-usable by all autonomic functions. Section 5 of [RFC7575]

Eckert, et al. Expires February 8, 2019 [Page 5]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

introduces that infrastructure and calls it the Autonomic Control
Plane (ACP). More descriptively it would be the "Autonomic
communications infrastructure for Management and Control". For
naming consistency with that prior document, this document continues
to use the name ACP though.

Today, the management and control plane of networks typically uses a
routing and forwarding table which is dependent on correct
configuration and routing. Misconfigurations or routing problems can
disrupt management and control channels. Traditionally, an out-of-
band network has been used to avoid or allow recovery from such
problems, or personnel are sent on site to access devices through
out-of-band management ports (also called craft ports, serial
console, management ethernet port). However, both options are
expensive.

In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of
the network they manage, to avoid impacting their own operations
through the configuration actions they take.

This document describes a modular design for a self-forming, self-
managing and self-protecting Autonomic Control Plane (ACP), which is
a virtual in-band network designed to be as independent as possible
of configuration, addressing and routing problems. The details how
this is achieved are described in Section 6. The ACP is designed to
remain operational even in the presence of configuration errors,
addressing or routing issues, or where policy could inadvertently
affect connectivity of both data packets or control packets.

This document uses the term "Data-Plane" to refer to anything in the
network nodes that is not the ACP, and therefore considered to be
dependent on (mis-)configuration. This Data-Plane includes both the
traditional forwarding-plane, as well as any pre-existing control-
plane, such as routing protocols that establish routing tables for
the forwarding plane.

The Autonomic Control Plane serves several purposes at the same time:

1. Autonomic functions communicate over the ACP. The ACP therefore
directly supports Autonomic Networking functions, as described in
[I-D.ietf-anima-reference-model]. For example, Generic Autonomic
Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely
inside the ACP and depends on the ACP as its "security and
transport substrate".

Eckert, et al. Expires February 8, 2019 [Page 6]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

quot;The status of the current row. This object is
used to add, delete, and disable rows in this
table. This row SHOULD NOT be removed until the
status is changed to destroy(6). When the status
changes to active(1), the collection in the sample
tables below will be activated.

The rows added to this table MUST have a valid
ifIndex, an ifType related to frame relay,
frsldPvcCtrlDlci MUST exist for the specified
ifIndex and frsldPvcCtrlStatus MUST have a
value of active(1).

The value of frsldPvcCtrlStatus MUST be active(1)
to transition this object to active(1). If
the value of frsldPvcCtrlStatus becomes anything
other than active(1) when the state of this object
is not active(1), this object SHOULD be set to
notReady(3).

The data in this table SHOULD persist through power
cycles. The symantics of readiness for the rows still
applies. This means that it is possible for a row to be
reprovisioned as notReady(3) if the underlying DLCI does
not persist."
::= { frsldSmplCtrlEntry 2 }

frsldSmplCtrlColPeriod OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The amount of time in seconds that defines a
period of collection for the statistics.
At the end of each period, the statistics will be
sampled and a row is added to the sample table."
::= { frsldSmplCtrlEntry 3 }

frsldSmplCtrlBuckets OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-create
STATUS current

Steinberger & Nicklass Standards Track [Page 33]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

DESCRIPTION
"The number of discrete buckets over which the
data statistics are sampled.

When this object is created or modified, the device
SHOULD attempt to set the frsldSmplCtrlBuckets-
Granted to a value as close as is possible
depending upon the implementation and the available
resources."
DEFVAL { 60 }
::= { frsldSmplCtrlEntry 4 }

frsldSmplCtrlBucketsGranted OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of discrete buckets granted. This
object will return 0 until frsldSmplCtrlStatus is
set to active(1). At that time the buckets will be
allocated depending upon implementation and
available resources."
::= { frsldSmplCtrlEntry 5 }

-- The Frame Relay Service Level Definitions PVC Data Table
--
-- This table contains the accumulated values of
-- the collected data. This table is the table that should
-- be referenced by external polling mechanisms if time
-- based polling be desired.

frsldPvcDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldPvcDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
data table.

This table contains accumulated values of the
collected data. It is the table that should be
referenced by external polling mechanisms if
time based polling be desired."
::= { frsldObjects 3 }

frsldPvcDataEntry OBJECT-TYPE
SYNTAX FrsldPvcDataEntry
MAX-ACCESS not-accessible

Steinberger & Nicklass Standards Track [Page 34]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions data table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP}
::= { frsldPvcDataTable 1 }

FrsldPvcDataEntry ::=
SEQUENCE {
frsldPvcDataMissedPolls Counter32,
frsldPvcDataFrDeliveredC Counter32,
frsldPvcDataFrDeliveredE Counter32,
frsldPvcDataFrOfferedC Counter32,
frsldPvcDataFrOfferedE Counter32,
frsldPvcDataDataDeliveredC Counter32,
frsldPvcDataDataDeliveredE Counter32,
frsldPvcDataDataOfferedC Counter32,
frsldPvcDataDataOfferedE Counter32,
frsldPvcDataHCFrDeliveredC Counter64,
frsldPvcDataHCFrDeliveredE Counter64,
frsldPvcDataHCFrOfferedC Counter64,
frsldPvcDataHCFrOfferedE Counter64,
frsldPvcDataHCDataDeliveredC Counter64,
frsldPvcDataHCDataDeliveredE Counter64,
frsldPvcDataHCDataOfferedC Counter64,
frsldPvcDataHCDataOfferedE Counter64,
frsldPvcDataUnavailableTime TimeTicks,
frsldPvcDataUnavailables Counter32
}

frsldPvcDataMissedPolls OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of polls that have been determined
to be missed. These polls are typically associated
with the calculation of delay but may also be
used for the calculation of other statistics. If an
anticipated poll is not received in a reasonable
amount of time, it should be counted as missed.
The value used to determine the reasonable amount
of time is contained in frsldPvcCtrlDelayTimeOut.

Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by

Steinberger & Nicklass Standards Track [Page 35]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcCtrlLastPurgeTime."
::= { frsldPvcDataEntry 1 }

frsldPvcDataFrDeliveredC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR.

Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcDataEntry 2 }

frsldPvcDataFrDeliveredE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR.

frsldPvcDataFrOfferedC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR.

Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by

Steinberger & Nicklass Standards Track [Page 36]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcDataEntry 4 }

frsldPvcDataFrOfferedE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.

frsldPvcDataDataDeliveredC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR.

frsldPvcDataDataDeliveredE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR.

Discontinuities in the value of this counter can

Steinberger & Nicklass Standards Track [Page 37]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

2. A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the (Data-
Plane) network in between is not yet configured; no Data-Plane
dependent bootstrap configuration is required. An example of
such a secure bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra].

3. An operator can use it to log into remote devices, even if the
network is misconfigured or not configured.

This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed.

The normative part of this document starts with Section 6, where the
ACP is specified. Section 7 defines normative how to support ACP on
L2 switches. Section 8 explains normative how non-ACP nodes and
networks can be integrated.

The remaining sections are non-normative: Section 9 reviews benefits
of the ACP (after all the details have been defined), Section 10
provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future standard or
propriety extensions that were considered not to be appropriate for
standardization in this document but were considered important to
document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document.

The ACP provides secure IPv6 connectivity, therefore it cannot only
be used as the secure connectivity for self-management as required
for the ACP in [RFC7575], but it can also be used as the secure
connectivity for traditional (centralized) management. The ACP can
be implemented and operated without any other components of autonomic
networks, except for the GRASP protocol which it leverages.

The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] describes how the ACP alone can be used to
provide secure and stable connectivity for autonomic and non-
autonomic Operations Administration and Management (OAM)
applications. That document also explains how existing management
solutions can leverage the ACP in parallel with traditional
management models, when to use the ACP and how to integrate with
potentially IPv4 only OAM backends.

Combining ACP with Bootstrapping Remote Secure Key Infrastructures
(BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the
"Autonomic Network Infrastructure" as defined in
[I-D.ietf-anima-reference-model], which provides autonomic

Eckert, et al. Expires February 8, 2019 [Page 7]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

connectivity (from ACP) with fully secure zero-touch (automated)
bootstrap from BRSKI. The ANI itself does not constitute an
Autonomic Network, but it allows the building of more or less
autonomic networks on top of it - using either centralized, Software
Defined Networking- (SDN-)style (see [RFC7426]) automation or
distributed automation via Autonomic Service Agents (ASA) / Autonomic
Functions (AF) - or a mixture of both. See
[I-D.ietf-anima-reference-model] for more information.

1.1. Applicability and Scope

Please see the following Terminology section (Section 2) for
explanations of terms used in this section.

The design of the ACP as defined in this document is considered to be
applicable to all types of "professionally managed" networks: Service
Provider, Local Area Network (LAN), Metro(politan networks), Wide
Area Network (WAN), Enterprise Information Technology (IT) and
->"Operational Technology" () (OT) networks. The ACP can operate
equally on layer 3 equipment and on layer 2 equipment such a bridges
(see Section 7). The encryption mechanism used by the ACP is defined
to be negotiable, therefore it can be extended to environments with
different encryption protocol preferences. The minimum
implementation requirements in this document attempt to achieve
maximum interoperability by requiring support for few options: IP
security (IPsec), see [RFC4301]) and datagram Transport Layer
Security version 1.2 (DTLS), see [RFC6347]), depending on type of
device.

The implementation footprint of the ACP consists of Public Key
Infrastructure (PKI) code for the ACP certificate, the GRASP
protocol, UDP, TCP and TLS (for security and reliability of GRASP),
the ACP secure channel protocol used (such as IPsec or DTLS), and an
instance of IPv6 packet forwarding and routing via the Routing
Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that
is separate from routing and forwarding for the Data-Plane (user
traffic).

The ACP uses only IPv6 to avoid complexity of dual-stack ACP
operations (IPv6/IPv4). Nevertheless, it can without any changes be
integrated into even otherwise IPv4-only network devices. The Data-
Plane itself would not need to change, it could continue to be IPv4
only. For such IPv4 only devices, the IPv6 protocol itself would be
additional implementation footprint only used for the ACP.

The protocol choices of the ACP are primarily based on wide use and
support in networks and devices, well understood security properties
and required scalability. The ACP design is an attempt to produce

Eckert, et al. Expires February 8, 2019 [Page 8]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

the lowest risk combination of existing technologies and protocols to
build a widely applicable operational network management solution:

RPL was chosen because it requires a smaller routing table footprint
in large networks compared to other routing protocols with an
autonomically configured single area. The deployment experience of
large scale Internet of Things (IoT) networks serves as the basis for
wide deployment experience with RPL. The profile chosen for RPL in
the ACP does not leverage any RPL specific forwarding plane features
(IPv6 extension headers), making its implementation a pure control
plane software requirement.

GRASP is the only completely novel protocol used in the ACP, and this
choice was necessary because there is no existing suitable protocol
to provide the necessary functions to the ACP, so GRASP was developed
to fill that gap.

The ACP design can be applicable to (cpu, memory) constrained devices
and (bitrate, reliability) constrained networks, but this document
does not attempt to define the most constrained type of devices or
networks to which the ACP is applicable. RPL and DTLS are two
protocol choices already making ACP more applicable to constrained
environments. See Appendix A.9 for discussions about how future
standards or proprietary extensions/variations of the ACP could
better meet different expectations from those on which the current
design is based.

2. Acronyms and Terminology (Informative)

[RFC Editor: WG/IETF/IESG review of the terms below asked for
references between these terms when they refer to each other. The
only option I could fin RFC/XML to point to a hanging text acronym
definition that also displays the actual term is the format="title"
version, which leads to references such as '->"ACP domain
certificate" ()'. I found no reasonable way to eliminate the
trailing '()' generated by this type of cross references. Can you
please take care of removing these artefacts during editing (after
conversion to nroff ?). I also created a ticket to ask for an
xml2rfc enhancement to avoid this in the future:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.

[RFC Editor: Question: Is it possible to change the first occurrences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but I did not want to
duplicate 50 first references - one reference for title mentioning
and one for RFC number.]

Eckert, et al. Expires February 8, 2019 [Page 9]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

In the rest of the document we will refer to systems using the ACP as
"nodes". Typically such a node is a physical (network equipment)
device, but it can equally be some virtualized system. Therefore, we
do not refer to them as devices unless the context specifically calls
for a physical system.

This document introduces or uses the following terms (sorted
alphabetically). Terms introduced are explained on first use, so
this list is for reference only.

ACP: "Autonomic Control Plane". The Autonomic Function as defined
in this document. It provides secure zero-touch (automated)
transitive (network wide) IPv6 connectivity for all nodes in the
same ACP domain as well as a GRASP instance running across this
ACP IPv6 connectivity. The ACP is primarily meant to be used as a
component of the ANI to enable Autonomic Networks but it can
equally be used in simple ANI networks (with no other Autonomic
Functions) or completely by itself.

ACP address: An IPv6 address assigned to the ACP node. It is stored
in the domain information field of the ->"ACP domain certificate"
().

ACP address range/set: The ACP address may imply a range or set of
addresses that the node can assign for different purposes. This
address range/set is derived by the node from the format of the
ACP address called the "addressing sub-scheme".

ACP connect interface: An interface on an ACP node providing access
to the ACP for non ACP capable nodes without using an ACP secure
channel. See Section 8.1.1.

ACP domain: The ACP domain is the set of nodes with ->"ACP domain
certificates" that allow them to authenticate each other as
members of the ACP domain. See also Section 6.1.2.

ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate
(LDevID) carrying the domain information field which is used by
the ACP to learn its address in the ACP and to derive and
cryptographically assert its membership in the ACP domain.

domain information (field): An rfc822Name information element (e.g.,
field) in the domain certificate in which the ACP relevant
information is encoded: the domain name and the ACP address.

ACP Loopback interface: The Loopback interface in the ACP Virtual
Routing and Forwarding (VRF) that has the ACP address assigned to
it.

Eckert, et al. Expires February 8, 2019 [Page 10]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

ACP network: The ACP network constitutes all the nodes that have
access to the ACP. It is the set of active and transitively
connected nodes of an ACP domain plus all nodes that get access to
the ACP of that domain via ACP edge nodes.

ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the
ACP. In the normal/simple case, the ACP has one ULA prefix, see
Section 6.10. The ACP routing table may include multiple ULA
prefixes if the "rsub" option is used to create addresses from
more than one ULA prefix. See Section 6.1.1. The ACP may also
include non-ULA prefixes if those are configured on ACP connect
interfaces. See Section 8.1.1.

ACP secure channel: A cryptographically authenticated and encrypted
data connection established between (normally) adjacent ACP nodes
to carry traffic of the ACP VRF secure and isolated from Data-
Plane traffic in-band over the same link/path as the Data-Plane.

ACP secure channel protocol: The protocol used to build an ACP
secure channel, e.g., Internet Key Exchange Protocol version 2
(IKEv2) with IPsec or Datagram Transport Layer Security (DTLS).

ACP virtual interface: An interface in the ACP VRF mapped to one or
more ACP secure channels. See Section 6.12.5.

AN "Autonomic Network": A network according to
[I-D.ietf-anima-reference-model]. Its main components are ANI,
Autonomic Functions and Intent.

(AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the
domain information field of the Domain Certificate. See
Section 6.1.1.

ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is
the infrastructure to enable Autonomic Networks. It includes ACP,
BRSKI and GRASP. Every Autonomic Network includes the ANI, but
not every ANI network needs to include autonomic functions beyond
the ANI (nor Intent). An ANI network without further autonomic
functions can for example support secure zero-touch (automated)
bootstrap and stable connectivity for SDN networks - see
[RFC8368].

ANIMA: "Autonomic Networking Integrated Model and Approach". ACP,
BRSKI and GRASP are products of the IETF ANIMA working group.

ASA: "Autonomic Service Agent". Autonomic software modules running
on an ANI device. The components making up the ANI (BRSKI, ACP,
GRASP) are also described as ASAs.

Eckert, et al. Expires February 8, 2019 [Page 11]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

Autonomic Function: A function/service in an Autonomic Network (AN)
composed of one or more ASA across one or more ANI nodes.

BRSKI: "Bootstrapping Remote Secure Key Infrastructures"
([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending
EST to enable secure zero-touch bootstrap in conjunction with ACP.
ANI nodes use ACP, BRSKI and GRASP.

Data-Plane: The counterpoint to the ACP VRF in an ACP node: all
routing and forwarding in the node other than the ACP VRF. In a
simple ACP or ANI node, the Data-Plane is typically provisioned by
means other than autonomically, for example manually (including
across the ACP) or via SDN controllers. In a fully Autonomic
Network node, the Data-Plane is managed autonomically via
Autonomic Functions and Intent. Note that other (non-ANIMA) RFC
use the Data-Plane to refer to what is better called the
forwarding plane. This is not the way the term is used in this
document!

device: A physical system, or physical node.

Enrollment: The process where a node presents identification (for
example through keying material such as the private key of an
IDevID) to a network and acquires a network specific identity and
trust anchor such as an LDevID.

EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard
protocol for enrollment of a node with an LDevID. BRSKI is based
on EST.

GRASP: "Generic Autonomic Signaling Protocol". An extensible
signaling protocol required by the ACP for ACP neighbor discovery.
The ACP also provides the "security and transport substrate" for
the "ACP instance of GRASP". This instance of GRASP runs across
the ACP secure channels to support BRSKI and other NOC/OAM or
Autonomic Functions. See [I-D.ietf-anima-grasp].

IDevID: An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that
establishes the identity of the node in the context of its vendor/
manufacturer such as device model/type and serial number. See
[AR8021]. IDevID cannot be used for the ACP because they are not
provisioned by the owner of the network, so they can not directly
indicate an ACP domain they belong to.

in-band (management): The type of management used predominantly in
IP based networks, not leveraging an ->"out-of-band network" ().
In in-band management, access to the managed equipment depends on

Eckert, et al. Expires February 8, 2019 [Page 12]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

the configuration of this equipment itself: interface, addressing,
forwarding, routing, policy, security, management. This
dependency makes in-band management fragile because the
configuration actions performed may break in-band management
connectivity. Breakage can not only be unintentional, it can
simply be an unavoidable side effect of being unable to create
configuration schemes where in-band management connectivity
configuration is unaffected by Data-Plane configuration. See also
->"(virtual) out-of-band network" ().

Intent: Policy language of an autonomic network according to
[I-D.ietf-anima-reference-model].

Loopback interface: The conventional name for an internal IP
interface to which addresses may be assigned, but which transmits
no external traffic.

LDevID: A occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcDataEntry 7 }

frsldPvcDataDataOfferedC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR.

frsldPvcDataDataOfferedE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.

frsldPvcDataHCFrDeliveredC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR. This object is a 64-bit version
of frsldPvcDataFrDeliveredC.

Steinberger & Nicklass Standards Track [Page 38]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcDataHCFrDeliveredE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR. This object is a 64-bit
version of frsldPvcDataFrDeliveredE.

frsldPvcDataHCFrOfferedC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR. This object is
a 64-bit version of frsldPvcDataFrOfferedC.

frsldPvcDataHCFrOfferedE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION

Steinberger & Nicklass Standards Track [Page 39]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR. This
object is a 64-bit version of frsldPvcDataFrOfferedE.

frsldPvcDataHCDataDeliveredC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR. This object is a 64-bit version of
frsldPvcDataDataDeliveredC.

frsldPvcDataHCDataDeliveredE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR. This object is a 64-bit
version of frsldPvcDataDataDeliveredE.

Steinberger & Nicklass Standards Track [Page 40]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcDataHCDataOfferedC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR. This object is
a 64-bit version of frsldPvcDataDataOfferedC.

frsldPvcDataHCDataOfferedE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.
This object is a 64-bit version of
frsldPvcDataDataOfferedE.

frsldPvcDataUnavailableTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time this PVC was declared unavailable
for any reason since this row was created."
REFERENCE
"FRF.13: Section 6.1 (OutageTime)"
::= { frsldPvcDataEntry 18 }

frsldPvcDataUnavailables OBJECT-TYPE
SYNTAX Counter32

Steinberger & Nicklass Standards Track [Page 41]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this PVC was declared unavailable
for any reason since this row was created.

-- The Frame Relay Service Level Definitions PVC Sample Table
--
-- This table contains the sampled delay, delivery and
-- availability information.

frsldPvcSampleTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldPvcSampleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
sample table."
::= { frsldObjects 4 }

frsldPvcSampleEntry OBJECT-TYPE
SYNTAX FrsldPvcSampleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions data sample table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP,
frsldSmplCtrlIdx, frsldPvcSmplIdx }
::= { frsldPvcSampleTable 1 }

FrsldPvcSampleEntry ::=
SEQUENCE {
frsldPvcSmplIdx Integer32,
frsldPvcSmplDelayMin Gauge32,
frsldPvcSmplDelayMax Gauge32,
frsldPvcSmplDelayAvg Gauge32,
frsldPvcSmplMissedPolls Gauge32,
frsldPvcSmplFrDeliveredC Gauge32,

"Local Device IDentity" is an X.509 certificate installed
during "enrollment". The Domain Certificate used by the ACP is an
LDevID. See [AR8021].

MIC: "Manufacturer Installed Certificate". Another word not used in
this document to describe an IDevID.

native interface: Interfaces existing on a node without
configuration of the already running node. On physical nodes
these are usually physical interfaces. On virtual nodes their
equivalent.

node: A system, e.g., supporting the ACP according to this document.
Can be virtual or physical. Physical nodes are called devices.

Node-ID: The identifier of an ACP node inside that ACP. It is the
last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of
the ACP address.

Operational Technology (OT): "https://en.wikipedia.org/wiki/
Operational_Technology" [1]: "The hardware and software dedicated
to detecting or causing changes in physical processes through
direct monitoring and/or control of physical devices such as
valves, pumps, etc.". OT networks are today in most cases well
separated from Information Technology (IT) networks.

(virtual) out-of-band network: An out-of-band network is a secondary
network used to manage a primary network. The equipment of the
primary network is connected to the out-of-band network via
dedicated management ports on the primary network equipment.
Serial (console) management ports were historically most common,

Eckert, et al. Expires February 8, 2019 [Page 13]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

higher end network equipment now also has ethernet ports dedicated
only for management. An out-of-band network provides management
access to the primary network independent of the configuration
state of the primary network. One of the goals of the ACP is to
provide this benefit of out-of-band networks virtually on the
primary network equipment. The ACP VRF acts as a virtual out of
band network device providing configuration independent management
access. The ACP secure channels are the virtual links of the ACP
virtual out-of-band network, meant to be operating independent of
the configuration of the primary network. See also ->"in-band
(management)" ().

RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. See [RFC6550].

MASA (service): "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet
used as part of the BRSKI protocol.

(ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software
and/or person) that is orchestrating the enrollment of ACP nodes
with the ACP domain certificate. ANI nodes use BRSKI, so ANI
registrars are also called BRSKI registrars. For non-ANI ACP
nodes, the registrar mechanisms are undefined by this document.
See Section 6.10.7. Renewal and other maintenance (such as
revocation) of ACP domain certificates may be performed by other
entities than registrars. EST must be supported for ACP domain
certificate renewal (see Section 6.1.3). BRSKI is an extension of
EST, so ANI/BRSKI registrars can easily support ACP domain
certificate renewal in addition to initial enrollment.

sUDI: "secured Unique Device Identifier". Another term not used in
this document to refer to an IDevID.

UDI: "Unique Device Identifier". In the context of this document
unsecured identity information of a node typically consisting of
at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID.

ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
address in the block fc00::/7, defined in [RFC4193]. It is the
approximate IPv6 counterpart of the IPv4 private address
([RFC1918]). The ULA Global ID prefix are the first 48-bits of a
ULA address. In this document it is abbreviated as "ULA prefix".

(ACP) VRF: The ACP is modeled in this document as a "Virtual Routing
and Forwarding" instance (VRF). This means that it is based on a
"virtual router" consisting of a separate IPv6 forwarding table to

Eckert, et al. Expires February 8, 2019 [Page 14]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

which the ACP virtual interfaces are attached and an associated
IPv6 routing table separate from the Data-Plane. Unlike the VRFs
on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF
does not have any special "core facing" functionality or routing/
mapping protocols shared across multiple VRFs. In vendor products
a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite.

(ACP) Zone: An ACP zone is a set of ACP nodes using the same zone
field value in their ACP address according to Section 6.10.3.
Zones are a mechanism to support structured addressing of ACP
addresses within the same /48-bit ULA prefix.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119],[RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Use Cases for an Autonomic Control Plane (Informative)

3.1. An Infrastructure for Autonomic Functions

Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimize
the complexity of the network. In this way, there is only need for a
single discovery mechanism, a single security mechanism, and single
instances of other processes that distributed functions require.

3.2. Secure Bootstrap over a not configured Network

Today, bootstrapping a new node typically requires all nodes between
a controlling node such as an SDN controller ("Software Defined
Networking", see [RFC7426]) and the new node to be completely and
correctly addressed, configured and secured. Bootstrapping and
configuration of a network happens in rings around the controller -
configuring each ring of devices before the next one can be
bootstrapped. Without console access (for example through an out-of-
band network) it is not possible today to make devices securely
reachable before having configured the entire network leading up to
them.

With the ACP, secure bootstrap of new devices and whole new networks
can happen without requiring any configuration of unconfigured
devices along the path: As long as all devices along the path support
ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP
across a whole network of unconfigured devices can be brought up
without operator/provisioning intervention. The ACP also provides

Eckert, et al. Expires February 8, 2019 [Page 15]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

additional security for any bootstrap mechanism, because it encrypts
the traffic along the path hop-by-hop.

3.3. Data-Plane Independent Permanent Reachability

Today, most critical control plane protocols and network management
protocols are using the Data-Plane of the network. This leads to
often undesirable dependencies between control and management plane
on one side and the Data-Plane on the other: Only if the forwarding
and control plane of the Data-Plane are configured correctly, will
the Data-Plane and the management plane work as expected.

Data-Plane connectivity can be affected by errors and faults, for
example misconfigurations that make AAA (Authentication,
Authorization and Accounting) servers unreachable or can lock an
administrator out of a device; routing or addressing issues can make
a device unreachable; shutting down interfaces over which a current
management session is running can lock an admin irreversibly out of
the device. Traditionally only out-of-band access can help recover
from such issues (such as serial console or ethernet management
port).

Data-Plane dependencies also affect applications in a Network
Operations Center (NOC) such as SDN controller applications: Certain
network changes are today hard to implement, because the change
itself may affect reachability of the devices. Examples are address
or mask changes, routing changes, or security policies. Today such
changes require precise hop-by-hop planning.

Note that specific control plane functions for the Data-Plane often
want to depend on forwarding of their packets via the Data-Plane:
Aliveness and routing protocol signaling packets across the Data-
Plane to verify reachability across the Data-Plane, using IPv4
signaling packets for IPv4 routing vs. IPv6 signaling packets for
IPv6 routing.

Assuming appropriate implementation (see Section 6.12.2 for more
details), the ACP provides reachability that is independent of the
Data-Plane. This allows the control plane and management plane to
operate more robustly:

o For management plane protocols, the ACP provides the functionality
of a Virtual out-of-band (VooB) channel, by providing connectivity
to all nodes regardless of their Data-Plane configuration, routing
and forwarding tables.

o For control plane protocols, the ACP allows their operation even
when the Data-Plane is temporarily faulty, or during transitional

Eckert, et al. Expires February 8, 2019 [Page 16]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

events, such as routing changes, which may affect the control
plane at least temporarily. This is specifically important for
autonomic service agents, which could affect Data-Plane
connectivity.

The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] explains this use case for the ACP in
significantly more detail and explains how the ACP can be used in
practical network operations.

4. Requirements (Informative)

The following requirements were identified as the basis for the
design of the ACP based on the above use-cases (Section 3). These
requirements are informative for this specification because they
(merely) represent the use-case requirements. The keywords are
highlighted ("_") to be different from RFC2119. The ACP as specified
in the normative parts of this document is meeting or exceeding these
use-case requirements:

ACP1: The ACP _SHOULD_ provide robust connectivity: As far as
possible, it should be independent of configured addressing,
configuration and routing. Requirements 2 and 3 build on this
requirement, but also have value on their own.

ACP2: The ACP _MUST_ have a separate address space from the Data-
Plane. Reason: traceability, debug-ability, separation from
Data-Plane, infrastructure security (filtering based on known
address space).

ACP3: The ACP _MUST_ use autonomically managed address space.
Reason: easy bootstrap and setup ("autonomic"); robustness
(admin can't mess things up so easily). This document
suggests using ULA addressing for this purpose ("Unique Local
Address", see [RFC4193]).

ACP4: The ACP _MUST_ be generic, that is it MUST be usable by all
the functions and protocols of the ANI. Clients of the ACP
MUST NOT be tied to a particular application or transport
protocol.

ACP5: The ACP _MUST_ provide security: Messages coming through the
ACP MUST be authenticated to be from a trusted node, and
SHOULD (very strong SHOULD) be encrypted.

Explanation for ACP4: In a fully autonomic network (AN), newly
written ASA could potentially all communicate exclusively via GRASP
with each other, and if that was assumed to be the only requirement

Eckert, et al. Expires February 8, 2019 [Page 17]
Steinberger & Nicklass Standards Track [Page 42]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcSmplFrDeliveredE Gauge32,
frsldPvcSmplFrOfferedC Gauge32,
frsldPvcSmplFrOfferedE Gauge32,
frsldPvcSmplDataDeliveredC Gauge32,
frsldPvcSmplDataDeliveredE Gauge32,
frsldPvcSmplDataOfferedC Gauge32,
frsldPvcSmplDataOfferedE Gauge32,
frsldPvcSmplHCFrDeliveredC CounterBasedGauge64,
frsldPvcSmplHCFrDeliveredE CounterBasedGauge64,
frsldPvcSmplHCFrOfferedC CounterBasedGauge64,
frsldPvcSmplHCFrOfferedE CounterBasedGauge64,
frsldPvcSmplHCDataDeliveredC CounterBasedGauge64,
frsldPvcSmplHCDataDeliveredE CounterBasedGauge64,
frsldPvcSmplHCDataOfferedC CounterBasedGauge64,
frsldPvcSmplHCDataOfferedE CounterBasedGauge64,
frsldPvcSmplUnavailableTime TimeTicks,
frsldPvcSmplUnavailables Gauge32,
frsldPvcSmplStartTime TimeStamp,
frsldPvcSmplEndTime TimeStamp
}

frsldPvcSmplIdx OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The bucket index of the current sample. This
increments once for each new bucket in the
table."
::= { frsldPvcSampleEntry 1 }

frsldPvcSmplDelayMin OBJECT-TYPE
SYNTAX Gauge32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum delay reported in microseconds measured
for any information packet that arrived during this
interval.

A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 2 }

frsldPvcSmplDelayMax OBJECT-TYPE
SYNTAX Gauge32

Steinberger & Nicklass Standards Track [Page 43]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The largest delay reported in microseconds measured
for any information packet that arrived during this
interval.

A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 3 }

frsldPvcSmplDelayAvg OBJECT-TYPE
SYNTAX Gauge32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average delay reported in microseconds measured
for all delay packets that arrived during this
interval.

A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 4 }

frsldPvcSmplMissedPolls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of polls that were missed during
this interval."
::= { frsldPvcSampleEntry 5 }

frsldPvcSmplFrDeliveredC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the

Steinberger & Nicklass Standards Track [Page 44]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrDeliveredC."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcSampleEntry 6 }

frsldPvcSmplFrDeliveredE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR during this interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrDeliveredE."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede))"
::= { frsldPvcSampleEntry 7 }

frsldPvcSmplFrOfferedC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrOfferedC."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcSampleEntry 8 }

frsldPvcSmplFrOfferedE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval.

Steinberger & Nicklass Standards Track [Page 45]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrOfferedE."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcSampleEntry 9 }

frsldPvcSmplDataDeliveredC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataDeliveredC."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcSampleEntry 10 }

frsldPvcSmplDataDeliveredE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlDeliveredRP and determined to have been
sent in excess of the CIR during this interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataDeliveredE."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcSampleEntry 11 }

frsldPvcSmplDataOfferedC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through

Steinberger & Nicklass Standards Track [Page 46]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcCtrlTransmitRP within CIR during this
interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataOfferredC."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcSampleEntry 12 }

frsldPvcSmplDataOfferedE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval.

If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataOfferedE."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcSampleEntry 13 }

frsldPvcSmplHCFrDeliveredC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval. This object
is a 64-bit version of frsldPvcSmplFrDeliveredC."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)&Internet-Draft An Autonomic Control Plane (ACP) August 2018

against the ACP, it would not need to provide IPv6 layer connectivity
between nodes, but only GRASP connectivity. Nevertheless, because
ACP also intends to support non-AN networks, it is crucial to support
IPv6 layer connectivity across the ACP to support any transport and
application layer protocols.

The ACP operates hop-by-hop, because this interaction can be built on
IPv6 link local addressing, which is autonomic, and has no dependency
on configuration (requirement 1). It may be necessary to have ACP
connectivity across non-ACP nodes, for example to link ACP nodes over
the general Internet. This is possible, but introduces a dependency
against stable/resilient routing over the non-ACP hops (see
Section 8.2).

5. Overview (Informative)

The Autonomic Control Plane is constructed in the following way (for
details, see Section 6):

1. An ACP node creates a Virtual Routing and Forwarding (VRF)
instance, or a similar virtual context.

2. It determines, following a policy, a candidate peer list. This
is the list of nodes to which it should establish an Autonomic
Control Plane. Default policy is: To all link-layer adjacent
nodes supporting ACP.

3. For each node in the candidate peer list, it authenticates that
node and negotiates a mutually acceptable channel type.

4. For each node in the candidate peer list, it then establishes a
secure tunnel of the negotiated type. The resulting tunnels are
then placed into the previously set up VRF. This creates an
overlay network with hop-by-hop tunnels.

5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a
Loopback interface assigned to the ACP VRF.

6. Each node runs a lightweight routing protocol, to announce
reachability of the virtual addresses inside the ACP (see
Section 6.12.5).

Note:

o Non-autonomic NMS ("Network Management Systems") or SDN
controllers have to be explicitly configured for connection into
the ACP.

Eckert, et al. Expires February 8, 2019 [Page 18]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

o Connecting over non-ACP Layer-3 clouds requires explicit
configuration. See Section 8.2.

o None of the above operations (except explicit configured ones) are
reflected in the configuration of the node.

The following figure illustrates the ACP.

ACP node 1 ACP node 2
................... ...................
secure . . secure . . secure
channel: +-----------+ : channel : +-----------+ : channel
..--------| ACP VRF |---------------------| ACP VRF |---------..
: / \ / \ <--routing--> / \ / \ :
: \ / \ / \ / \ / :
..--------| Loopback |---------------------| Loopback |---------..
: | interface | : : | interface | :
: +-----------+ : : +-----------+ :
: : : :
: Data-Plane :...............: Data-Plane :
: : link : :
:.................: :.................:

Figure 1: ACP VRF and secure channels

The resulting overlay network is normally based exclusively on hop-
by-hop tunnels. This is because addressing used on links is IPv6
link local addressing, which does not require any prior set-up. In
this way the ACP can be built even if there is no configuration on
the node, or if the Data-Plane has issues such as addressing or
routing problems.

6. Self-Creation of an Autonomic Control Plane (ACP) (Normative)

This section describes the components and steps to set up an
Autonomic Control Plane (ACP), and highlights the key properties
which make it "indestructible" against many inadvertent changes to
the Data-Plane, for example caused by misconfigurations.

An ACP node can be a router, switch, controller, NMS host, or any
other IP capable node. Initially, it must have it's ACP domain
certificate, as well as an (empty) ACP Adjacency Table (described in
Section 6.2). It then can start to discover ACP neighbors and build
the ACP. This is described step by step in the following sections:

Eckert, et al. Expires February 8, 2019 [Page 19]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

6.1. ACP Domain, Certificate and Network

The ACP relies on group security. An ACP domain is a group of nodes
that trust each other to participate in ACP operations. To establish
trust, each ACP member requires keying material: An ACP node MUST
have a certificate (LDevID) and a Trust Anchor (TA) consisting of a
certificate (chain) used to sign the LDevID of all ACP domain
members. The LDevID is used to cryptographically authenticate the
membership of its owner node in the ACP domain to other ACP domain
members, the TA is used to authenticate the ACP domain membership of
other nodes (see Section 6.1.2).

The LDevID is called the ACP domain certificate, the TA is the
Certificate Authority (CA) of the ACP domain.

The ACP does not mandate specific mechanisms by which this keying
material is provisioned into the ACP node, it only requires the
Domain information field as specified in Section 6.1.1 in its domain
certificate as well as those of candidate ACP peers. See
Appendix A.2 for more information about enrollment or provisioning
options.

This document uses the term ACP in many places where the Autonomic
Networking reference documents [RFC7575] and
[I-D.ietf-anima-reference-model] use the word autonomic. This is
done because those reference documents consider (only) fully
autonomic networks and nodes, but support of ACP does not require
support for other components of autonomic networks. Therefore the
word autonomic might be misleading to operators interested in only
the ACP.

[RFC7575] defines the term "Autonomic Domain" as a collection of
autonomic nodes. ACP nodes do not need to be fully autonomic, but
when they are, then the ACP domain is an autonomic domain. Likewise,
[I-D.ietf-anima-reference-model] defines the term "Domain
Certificate" as the certificate used in an autonomic domain. The ACP
domain certificate is that domain certificate when ACP nodes are
(fully) autonomic nodes. Finally, this document uses the term ACP
network to refer to the network created by active ACP nodes in an ACP
domain. The ACP network itself can extend beyond ACP nodes through
the mechanisms described in Section 8.1.

The ACP domain certificate SHOULD be used for any authentication
between nodes with ACP domain certificates (ACP nodes and NOC nodes)
where the required condition is ACP domain membership, such as ACP
node to NOC/OAM end-to-end security and ASA to ASA end-to-end
security. Section 6.1.2 defines this "ACP domain membership check".
The uses of this check that are standardized in this document are for

Eckert, et al. Expires February 8, 2019 [Page 20]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

the establishment of ACP secure channels (Section 6.6) and for ACP
GRASP (Section 6.8.2).

6.1.1. Certificate Domain Information Field

Information about the domain MUST be encoded in the domain
certificate in a subjectAltName / rfc822Name field according to the
following ABNF definition ([RFC5234]):

[RFC Editor: Please substitute SELF in all occurrences of rfcSELF in
this document with the RFC number assigned to this document and
remove this comment line]

domain-information = local-part "@" acp-domain-name
local-part = key [ "." local-info ]
key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32hex-dig | 0
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
routing-subdomain = [ rsub " ." ] acp-domain-name
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5
extensions = *( "+" extension )
extension = ; future standard definition.
; Must fit RFC5322 simple dot-atom format.

Example:
domain-information = rfcSELF+fd89b714f3db00000200000064000000
+area51.research@acp.example.com
acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com

Figure 2: ACP Domain Information Field ABNF

Nodes complying with this specification MUST be able to receive their
ACP address through the domain certificate, in which case their own
ACP domain certificate MUST have the 32hex-dig "acp-address" field.
Nodes complying with this specification MUST also be able to
authenticate nodes as ACP domain members / ACP secure channel peers
when they have an empty or 0-value acp-address field. See
Section 6.1.2.

"acp-domain-name" is used to indicate the ACP Domain across which all
ACP nodes trust each other and are willing to build ACP channels to
each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN
of a DNS domain owned by the operator assigning the certificate.
This is a simple method to ensure that the domain is globally unique
and collision of ACP addresses would therefore only happen due to ULA

Eckert, et al. Expires February 8, 2019 [Page 21]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

hash collisions. If the operator does not own any FQDN, it should
choose a string (in FQDN format) that it intends to be equally
unique.

"routing-subdomain" is the autonomic subdomain composed of "rsub" and
"acp-domain-name". "rsub" is optional. When not present, "routing-
subdomain" is the same as "acp-domain-name". "routing-subdomain"
determines the /48 ULA prefix for ACP addresses. "rsub" therefore
allows to use multiple /48 ULA prefixes in an ACP domain. See
Appendix A.7 for example use-cases.

The optional "extensions"
::= { frsldPvcSampleEntry 14 }

frsldPvcSmplHCFrDeliveredE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been

Steinberger & Nicklass Standards Track [Page 47]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

sent in excess of the CIR during this interval.
This object is a 64-bit version of frsldPvcSmpl-
FrDeliveredE."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede)"
::= { frsldPvcSampleEntry 15 }

frsldPvcSmplHCFrOfferedC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval. This object is a 64-bit version of
frsldPvcSmplFrOfferedC."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcSampleEntry 16 }

frsldPvcSmplHCFrOfferedE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval. This object is a 64-bit
version of frsldPvcSmplFrOfferedE."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcSampleEntry 17 }

frsldPvcSmplHCDataDeliveredC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval. This value
is a 64-bit version of frsldPvcSmplDataDeliveredC."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcSampleEntry 18 }

frsldPvcSmplHCDataDeliveredE OBJECT-TYPE
SYNTAX CounterBasedGauge64

Steinberger & Nicklass Standards Track [Page 48]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR during this interval. This
value is a 64-bit version of frsldPvcSmplData-
DeliveredE."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcSampleEntry 19 }

frsldPvcSmplHCDataOfferedC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval. This value is a 64-bit version of
frsldPvcSmplDataOfferedC."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcSampleEntry 20 }

frsldPvcSmplHCDataOfferedE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval. This object is a 64-bit
version of frsldPvcSmplDataOfferedE."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcSampleEntry 21 }

frsldPvcSmplUnavailableTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time this PVC was declared
unavailable for any reason during this interval."
REFERENCE
"FRF.13: Section 6.1 (OutageTime)"
::= { frsldPvcSampleEntry 22 }

Steinberger & Nicklass Standards Track [Page 49]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcSmplUnavailables OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this PVC was declared
unavailable for any reason during this interval."
REFERENCE
"FRF.13: Section 6.1 (OutageCount)"
::= { frsldPvcSampleEntry 23 }

frsldPvcSmplStartTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this sample interval
started."
::= { frsldPvcSampleEntry 24 }

frsldPvcSmplEndTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this sample interval
ended. No data will be reported and the row will
not appear in the table until the sample has
been collected."
::= { frsldPvcSampleEntry 25 }

-- Capabilities Group
-- This group provides capabilities objects for the tables
-- that control configuration.

frsldPvcCtrlWriteCaps OBJECT-TYPE
SYNTAX BITS {
frsldPvcCtrlStatus(0),
frsldPvcCtrlPacketFreq(1),
frsldPvcCtrlDelayFrSize(2),
frsldPvcCtrlDelayType(3),
frsldPvcCtrlDelayTimeOut(4),
frsldPvcCtrlPurge(5),
frsldPvcCtrlDeleteOnPurge(6)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION

Steinberger & Nicklass Standards Track [Page 50]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

"This object specifies the write capabilities
for the read-create objects of the PVC Control
table. If the corresponding bit is enabled (1),
the agent supports writes to that object."
::= { frsldCapabilities 1 }

frsldSmplCtrlWriteCaps OBJECT-TYPE
SYNTAX BITS {
frsldSmplCtrlStatus(0),
frsldSmplCtrlBuckets(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the write capabilities
for the read-create objects of the Sample Control
table. If the corresponding bit is enabled (1),
the agent supports writes to that object."
::= { frsldCapabilities 2 }

frsldRPCaps OBJECT-TYPE
SYNTAX BITS {
srcLocalRP(0),
ingTxLocalRP(1),
tpTxLocalRP(2),
eqiTxLocalRP(3),
eqoTxLocalRP(4),
otherTxLocalRP(5),
srcRemoteRP(6),
ingTxRemoteRP(7),
tpTxRemoteRP(8),
eqiTxRemoteRP(9),
eqoTxRemoteRP(10),
otherTxRemoteRP(11),
desLocalRP(12),
ingRxLocalRP(13),
tpRxLocalRP(14),
eqiRxLocalRP(15),
eqoRxLocalRP(16),
otherRxLocalRP(17),
desRemoteRP(18),
ingRxRemoteRP(19),
tpRxRemoteRP(20),
eqiRxRemoteRP(21),
eqoRxRemoteRP(22),
otherRxRemoteRP(23)
}
MAX-ACCESS read-only

Steinberger & Nicklass Standards Track [Page 51]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

STATUS current
DESCRIPTION
"This object specifies the reference points that
the agent supports. This object allows the management
application to discover which rows can be created on
a specific device."
::= { frsldCapabilities 3 }

frsldMaxPvcCtrls OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of control rows that can be created
in frsldPvcCtrlTable. Sets to this object lower than
the current value of frsldNumPvcCtrls should result in
inconsistentValue."
::= { frsldCapabilities 4 }

frsldNumPvcCtrls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of rows in frsldPvcCtrlTable."
::= { frsldCapabilities 5 }

frsldMaxSmplCtrls OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of control rows that can be created
in frsldSmplCtrlTable. Sets to this object lower than
the current value of frsldNumSmplCtrls should result in
inconsistentValue."
::= { frsldCapabilities 6 }

frsldNumSmplCtrls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
quot; field is used for future standardized
extensions to this specification. It MUST be ignored if present and
not understood.

Formatting notes:

o "rsub" needs to be in the "local-part": If the format just had
routing-subdomain as the domain part of the domain-information,
rsub and acp-domain-name could not be separated from each other.
It also makes acp-domain-name a valid e-mail target across all
routing-subdomains.

o "acp-address" cannot use standard IPv6 address formats because it
must match the simple dot-atom format of [RFC5322]. The character
":" is not allowed in that format.

o If "acp-address" is empty, and "rsub" is empty too, the "local-
part" will have the format "rfcSELF + + extension(s)". The two
plus characters are necessary so the node can unambiguously parse
that both "acp-address" and "rsub" are empty.

o The maximum size of "domain-information" is 254 characters and the
maximum size of node-info is 64 characters according to [RFC5280]
that is referring to [RFC2821] (superseded by [RFC5321]).

The subjectAltName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons:

o It should be possible to share the LDevID with other uses beside
the ACP. Therefore, the information element required for the ACP
should be encoded so that it minimizes the possibility of creating
incompatibilities with such other uses.

o The information for the ACP should not cause incompatibilities
with any pre-existing ASN.1 software. This eliminates the
introduction of a novel information element because that could
require extensions to such pre-existing ASN.1 parsers.

Eckert, et al. Expires February 8, 2019 [Page 22]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

o subjectAltName / rfc822Name is a pre-existing element that must be
supported by all existing ASN.1 parsers for LDevID.

o The element required for the ACP should not be misinterpreted by
any other uses of the LDevID. If the element used for the ACP is
interpreted by other uses, the impact should be benign.

o Using an IP address format encoding could result in non-benign
misinterpretation of the domain information field; other uses
unaware of the ACP could try to do something with the ACP address
that would fail to work correctly. For example, the address could
be interpreted to be an address of the node which does not belong
to the ACP VRF.

o At minimum, both the AN domain name and the non-domain name
derived part of the ACP address need to be encoded in one or more
appropriate fields of the certificate, so there are not many
alternatives with pre-existing fields where the only possible
conflicts would likely be beneficial.

o rfc822Name encoding is quite flexible. The ACP information field
encodes the full ACP address AND the domain name with rsub part,
so that it is easier to examine/use the "domain information
field".

o The format of the rfc822Name is chosen so that an operator can set
up a mailbox called rfcSELF@<domain> that would receive emails
sent towards the rfc822Name of any node inside a domain. This is
possible because in many modern mail systems, components behind a
"+" character are considered part of a single mailbox. In other
words, it is not necessary to set up a separate mailbox for every
ACP node, but only one for the whole domain.

o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be
mail to that mailbox.

See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field.

6.1.2. ACP domain membership check

The following points constitute the ACP domain membership check of a
candidate peer certificate, independent of the protocol used:

1: The peer certificate is valid (lifetime).

Eckert, et al. Expires February 8, 2019 [Page 23]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

2: The peer has proved ownership of the private key associated with
the certificate's public key.

3: The peer's certificate is signed by one of the trust anchors
associated with the ACP domain certificate.

4: If the node certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate must be valid
according to those criteria: An OCSP check for the peer's
certificate across the ACP must succeed or the peer certificate
must not be listed in the CRL retrieved from the CDP.

5: The peer's certificate has a syntactically valid ACP domain
information field (encoded as subjectAltName / rfc822Name) and the
acp-domain-name in that peer's domain information field is the
same as in this ACP node's certificate.

Only when checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is
performed:

6: The candidate peer certificate's ACP domain information field
has a non-empty acp-address field (either 32hex-dig or 0,
according to Figure 2).

Rule 6: for the establishment of ACP secure channels ensures that
they will only be built between nodes which indicate through the acp-
address in their ACP domain certificate the ability and permission by
the Registrar to participate in ACP secure-channels.

Nodes with an empty acp-address field can only use their ACP domain
certificate for non-ACP-secure channel authentication purposes.

The special value 0 in an ACP certificates acp-address field is used
for nodes that can and should determine their ACP address through
other mechanisms than learning it through their ACP domain
certificate. These ACP nodes are permitted to establish ACP secure
channels. Mechanisms for those nodes to determine their ACP address
are outside the scope of this specification.

6.1.3. Certificate Maintenance

ACP nodes MUST support certificate renewal via EST ("Enrollment over
Secure Transport", see [RFC7030]) and MAY support other mechanisms.
An ACP network MUST have at least one ACP node supporting EST server
functionality across the ACP so that EST renewal is useable.

Eckert, et al. Expires February 8, 2019 [Page 24]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

ACP nodes SHOULD be able to remember the EST server from which they
last renewed their ACP domain certificate and SHOULD provide the
ability for this remembered EST server to also be set by the ACP
Registrar (see Section 6.10.7) that initially enrolled the ACP device
with its ACP domain certificate. When BRSKI (see
[I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of
the BRSKI registrar from the BRSKI TLS connection SHOULD be
remembered and used for the next renewal via EST if that registrar
also announces itself as an EST server via GRASP (see next section)
on its ACP address.

6.1.3.1. GRASP objective for EST server

ACP nodes that are EST servers MUST announce their service via GRASP
in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp],
section 2.8.11 for the definition of this message type:

Example:

[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR,
h'fd89b714f3db0000200000064000001', TCP, 80]
]

Figure 3: GRASP SRV.est example

The formal definition of the objective in Concise data definition
language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows:

flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]

objective = ["SRV.est", objective-flags, loop-count,
objective-value]

objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; recommended
objective-value = any ; Not used (yet)

Figure 4: GRASP SRV.est definition

The objective value "SRV.est" indicates that the objective is an
[RFC7030] compliant EST server because "The current number of rows in frsldSmplCtrlTable."
::= { frsldCapabilities 7 }

-- Conformance Information

Steinberger & Nicklass Standards Track [Page 52]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldMIBGroups OBJECT IDENTIFIER ::= { frsldConformance 1 }
frsldMIBCompliances OBJECT IDENTIFIER ::= { frsldConformance 2 }

--
-- Compliance Statements
--

frsldCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
which support with Frame Relay Service Level
Definitions. This group defines the minimum
level of support required for compliance."
MODULE -- this module
MANDATORY-GROUPS { frsldPvcReqCtrlGroup,
frsldPvcReqDataGroup,
frsldCapabilitiesGroup}

GROUP frsldPvcHCFrameDataGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces with corresponding instance of ifSpeed
greater than 650,000,000 bits/second."

GROUP frsldPvcHCOctetDataGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces with corresponding instance of ifSpeed
greater than 650,000,000 bits/second."

GROUP frsldPvcPacketGroup
DESCRIPTION
"This group is optional. Network interfaces that
allow control of the packets used to collect
information are encouraged to implement this
group."

GROUP frsldPvcDelayCtrlGroup
DESCRIPTION
"This group is optional. Network interfaces that
offer control of the delay measurement are
strongly encouraged to implement this group."

GROUP frsldPvcSampleCtrlGroup
DESCRIPTION
"This group is mandatory only for those network

Steinberger & Nicklass Standards Track [Page 53]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

interfaces that allow data sampling."

GROUP frsldPvcDelayDataGroup
DESCRIPTION
"This group is only mandatory when
frsldPvcDelayCtrlGroup is implemented. It is
strongly encouraged that any device capable
of measuring delay implement this group."

GROUP frsldPvcSampleDelayGroup
DESCRIPTION
"This group is only mandatory when both
frsldPvcSampleCtrlGroup and frsldPvcDelayDataGroup
are supported."

GROUP frsldPvcSampleDataGroup
DESCRIPTION
"This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."

GROUP frsldPvcSampleHCFrameGroup
DESCRIPTION
"This group is mandatory whenever both
frsldPvcSampleCtrlGroup and frsldPvcHCFrameDataGroup
are supported."

GROUP frsldPvcSampleHCDataGroup
DESCRIPTION
"This group is mandatory whenever both
frsldPvcSampleCtrlGroup and frsldPvcHCOctetDataGroup
are supported."

GROUP frsldPvcSampleAvailGroup
DESCRIPTION
"This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."

GROUP frsldPvcSampleGeneralGroup
DESCRIPTION
&"est" is an [RFC6335]
registered service name for [RFC7030]. Objective-value MUST be
ignored if present. Backward compatible extensions to [RFC7030] MAY

Eckert, et al. Expires February 8, 2019 [Page 25]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

be indicated through objective-value. Non [RFC7030] compatible
certificate renewal options MUST use a different objective-name.

The M_FLOOD message MUST be sent periodically. The default SHOULD be
60 seconds, the value SHOULD be operator configurable but SHOULD be
not smaller than 60 seconds. The frequency of sending MUST be such
that the aggregate amount of periodic M_FLOODs from all flooding
sources cause only negligible traffic across the ACP. The time-to-
live (ttl) parameter SHOULD be 3.5 times the period so that up to
three consecutive messages can be dropped before considering an
announcement expired. In the example above, the ttl is 210000 msec,
3.5 times 60 seconds. When a service announcer using these
parameters unexpectedly dies immediately after sending the M_FLOOD,
receivers would consider it expired 210 seconds later. When a
receiver tries to connect to this dead service before this timeout,
it will experience a failing connection and use that as an indication
that the service is dead and select another instance of the same
service instead.

6.1.3.2. Renewal

When performing renewal, the node SHOULD attempt to connect to the
remembered EST server. If that fails, it SHOULD attempt to connect
to an EST server learned via GRASP. The server with which
certificate renewal succeeds SHOULD be remembered for the next
renewal.

Remembering the last renewal server and preferring it provides
stickiness which can help diagnostics. It also provides some
protection against off-path compromised ACP members announcing bogus
information into GRASP.

Renewal of certificates SHOULD start after less than 50% of the
domain certificate lifetime so that network operations has ample time
to investigate and resolve any problems that causes a node to not
renew its domain certificate in time - and to allow prolonged periods
of running parts of a network disconnected from any CA.

6.1.3.3. Certificate Revocation Lists (CRLs)

The ACP node SHOULD support Certificate Revocation Lists (CRL) via
HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s)
MUST be indicated in the Domain Certificate when used. If the CDP
URL uses an IPv6 address (ULA address when using the addressing rules
specified in this document), the ACP node will connect to the CDP via
the ACP. If the CDP URL uses an IPv6 address (ULA address when using
the addressing rules specified in this document), the ACP node will

Eckert, et al. Expires February 8, 2019 [Page 26]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

connect to the CDP via the ACP. If the CDP uses a domain name, the
ACP node will connect to the CDP via the Data-Plane.

It is common to use domain names for CDP(s), but there is no
requirement for the ACP to support DNS. Any DNS lookup in the Data-
Plane is not only a possible security issue, but it would also not
indicate whether the resolved address is meant to be reachable across
the ACP. Therefore, the use of an IPv6 address versus the use of a
DNS name doubles as an indicator whether or not to reach the CDP via
the ACP.

A CDP can be reachable across the ACP either by running it on a node
with ACP or by connecting its node via an ACP connect interface (see
Section 8.1). The CDP SHOULD use an ACP domain certificate for its
HTTPs connections. The connecting ACP node SHOULD verify that the
CDP certificate used during the HTTPs connection has the same ACP
address as indicated in the CDP URL of the nodes ACP domain
certificate

6.1.3.4. Lifetimes

Certificate lifetime may be set to shorter lifetimes than customary
(1 year) because certificate renewal is fully automated via ACP and
EST. The primary limiting factor for shorter certificate lifetimes
is load on the EST server(s) and CA. It is therefore recommended
that ACP domain certificates are managed via a CA chain where the
assigning CA has enough performance to manage short lived
certificates. See also Section 10.2.4 for discussion about an
example setup achieving this.

When certificate lifetimes are sufficiently short, such as few hours,
certificate revocation may not be necessary, allowing to simplify the
overall certificate maintenance infrastructure.

See Appendix A.2 for further optimizations of certificate maintenance
when BRSKI can be used ("Bootstrapping Remote Secure Key
Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]).

6.1.3.5. Re-enrollment

An ACP node may determine that its ACP domain certificate has
expired, for example because the ACP node was powered down or
disconnected longer than its certificate lifetime. In this case, the
ACP node SHOULD convert to a role of a re-enrolling candidate ACP
node.

In this role, the node does maintain the trust anchor and certificate
chain associated with its ACP domain certificate exclusively for the

Eckert, et al. Expires February 8, 2019 [Page 27]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

purpose of re-enrollment, and attempts (or waits) to get re-enrolled
with a new ACP certificate. The details depend on the mechanisms/
protocols used by the ACP registrars.

Please refer to Section 6.10.7 for explanations about ACP registrars
and vouchers as used in the following text.

When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re-
enrolling candidate ACP node would attempt to enroll like a candidate
ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID,
it SHOULD first attempt to use its ACP domain certificate in the
BRSKI TLS authentication. The BRSKI registrar MAY honor this
certificate beyond its expiration date purely for the purpose of re-
enrollment. Using the ACP node's domain certificate allows the BRSKI
registrar to learn that nodes ACP domain information field, so that
the BRSKI registrar can re-assign the same ACP address information to
the ACP node in the new ACP domain certificate.

If the BRSKI registrar denies the use of the old ACP domain
certificate, the re-enrolling candidate ACP node MUST re-attempt re-
enrollment using its IDevID as defined in BRSKI during the TLS
connection setup.

Both when the BRSKI connection is attempted with the old ACP domain
certificate or the IDevID, the re-enrolling candidate ACP node SHOULD
authenticate the BRSKI registrar during TLS connection setup based on
its existing trust anchor/certificate chain information associated
with its old ACP certificate. The re-enrolling candidate ACP node
SHOULD only request a voucher from the BRSKI registrar when this
authentication fails during TLS connection setup.

When other mechanisms than BRSKI are used for ACP domain certificate
enrollment, the principles of the re-enrolling candidate ACP node are
the same. The re-enrolling candidate ACP node attempts to
authenticate any ACP registrar peers during re-enrollment protocol/
mechanisms via its existing certificate chain/trust anchor and
provides its existing ACP domain certificate and other identification
(such as the IDevID) as necessary to the registrar.

Maintaining existing trust anchor information is especially important
when enrollment mechanisms are used that unlike BRSKI do not leverage
a voucher mechanism to authenticate the ACP registrar and where
therefore the injection of certificate failures could otherwise make
the ACP node easily attackable remotely.

When using BRSKI or other protocol/mechanisms supporting vouchers,
maintaining existing trust anchor information allows for re-
enrollment of expired ACP certificates to be more lightweight,

Eckert, et al. Expires February 8, 2019 [Page 28]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

especially in environments where repeated acquisition of vouchers
during the lifetime of ACP nodes may be operationally expensive or
otherwise undesirable.

6.1.3.6. Failing Certificates

An ACP domain certificate is called failing in this document, if/when
the ACP node can determine that it was revoked (or explicitly not
renewed), or in the absence of such explicit local diagnostics, when
the ACP node fails to connect to other ACP nodes in the same ACP
domain using its ACP certificate. For connection failures to
determine the ACP domain certificate as the culprit, the peer should
pass the domain membership check (Section 6.1.2) and other reasons
for the connection failure can be excluded because of the connection
error diagnostics.

This type of failure can happen during setup/refresh of a secure ACP
channel connections or any other use of the ACP domain certificate,
such as for the TLS connection to an EST server for the renewal of
the ACP domain certificate.

Example reasons for failing certificates that the ACP node can only
discover through connection failure are that the domain certificate
or any of its signing certificates could have been revoked or may
have expired, but the ACP node cannot self-diagnose this condition
directly. Revocation information or clock synchronization may only
be available across the ACP, but the ACP node cannot build ACP secure
channels because ACP peers reject the ACP node's domain certificate.

ACP nodes SHOULD support the option to determines whether its ACP
certificate is failing, and when it does, put itself into the role of
a re-enrolling candidate ACP node as explained above
(Section 6.1.3.5).

6.2. ACP Adjacency Table

To know to which nodes to establish an ACP channel, every ACP node
maintains an adjacency table. The adjacency table contains
information about adjacent ACP nodes, at a minimum: Node-ID
(identifier of the node inside the ACP, see Section 6.10.3 and
Section 6.10.5), interface on which neighbor was discovered (by GRASP
as explained below), link-local IPv6 address of neighbor on that
interface, certificate (including domain information field). An ACP
node MUST maintain this adjacency table up to date. This table is
used to determine to which neighbor an ACP connection is established.

Where the next ACP node is not directly adjacent (i.e., not on a link
connected to this node), the information in the adjacency table can

Eckert, et al. Expires February 8, 2019 [Page 29]
quot;This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."

OBJECT frsldPvcCtrlStatus
SYNTAX RowStatus { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Row creation can be done outside of the scope of
the SNMP protocol. If this object is implemented

Steinberger & Nicklass Standards Track [Page 54]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

with max-access of read-only, then the only value
that MUST be returned is active(1) and
frsldPvcCtrlWriteCaps MUST return 0 for the
frsldPvcCtrlStatus(0) bit."

OBJECT frsldPvcCtrlPurge
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. If this object is
implemented with a max-access of read-only, then
the frsldPvcCtrlPurge(5) bit must return 0."

OBJECT frsldPvcCtrlDeleteOnPurge
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. If this object is
implemented with a max-access of read-only, then
the frsldPvcCtrlDeleteOnPurge(6) bit must return
0."

OBJECT frsldMaxPvcCtrls
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required if the device either
dynamically allocates memory or statically allocates
a fixed number of entries. In the case of static
allocation, the device should always report the
correct maximum number of controls. In the case
of dynamic allocation, the device SHOULD always
report a number greater than frsldNumPvcCtrls
when allocation is possible and a number equal to
frsldNumPvcCtrls when allocation is not possible."
OBJECT frsldMaxSmplCtrls
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required if the device either
dynamically allocates memory or statically allocates
a fixed number of entries. In the case of static
allocation, the device should always report the
correct maximum number of controls. In the case
of dynamic allocation, the device SHOULD always
report a number greater than frsldNumSmplCtrls
when allocation is possible and a number equal to
frsldNumSmplCtrls when allocation is not possible."

::= { frsldMIBCompliances 1 }

Steinberger & Nicklass Standards Track [Page 55]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

-- Units of Conformance
--
frsldPvcReqCtrlGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlStatus,
frsldPvcCtrlPurge,
frsldPvcCtrlDeleteOnPurge,
frsldPvcCtrlLastPurgeTime
}
STATUS current
DESCRIPTION
"A collection of required objects providing
control information applicable to a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 1 }

frsldPvcPacketGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlPacketFreq
}
STATUS current
DESCRIPTION
"A collection of optional objects providing packet
level control information applicable to a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 2 }

frsldPvcDelayCtrlGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlDelayFrSize,
frsldPvcCtrlDelayType,
frsldPvcCtrlDelayTimeOut
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
control information applicable to a PVC which
implements Service Level Definitions.

If this group is implemented, frsldPvcPacketGroup
and frsldPvcDelayDataGroup MUST also be implemented."
::= { frsldMIBGroups 3 }

frsldPvcSampleCtrlGroup OBJECT-GROUP
OBJECTS {
frsldSmplCtrlStatus,
frsldSmplCtrlColPeriod,
frsldSmplCtrlBuckets,

Steinberger & Nicklass Standards Track [Page 56]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldSmplCtrlBucketsGranted
}
STATUS current
DESCRIPTION
"A collection of optional objects providing sample
control information applicable to a PVC which
implements Service Level Definitions.

If this group is implemented, frsldPvcReqDataGroup
and frsldPvcSampleGeneralGroup MUST also be
implemented."
::= { frsldMIBGroups 4 }

frsldPvcReqDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataFrDeliveredC,
frsldPvcDataFrDeliveredE,
frsldPvcDataFrOfferedC,
frsldPvcDataFrOfferedE,
frsldPvcDataDataDeliveredC,
frsldPvcDataDataDeliveredE,
frsldPvcDataDataOfferedC,
frsldPvcDataDataOfferedE,
frsldPvcDataUnavailableTime,
frsldPvcDataUnavailables
}
STATUS current
DESCRIPTION
"A collection of required objects providing data
collected on a PVC which implements Service
Level Definitions."
::= { frsldMIBGroups 5 }

frsldPvcDelayDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataMissedPolls
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
data collected on a PVC which implements Service
Level Definitions.

If this group is implemented, frsldPvcDelayCtrlGroup
MUST also be implemented."
::= { frsldMIBGroups 6 }

frsldPvcHCFrameDataGroup OBJECT-GROUP

Steinberger & Nicklass Standards Track [Page 57]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

OBJECTS {
frsldPvcDataHCFrDeliveredC,
frsldPvcDataHCFrDeliveredE,
frsldPvcDataHCFrOfferedC,
frsldPvcDataHCFrOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity frame data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 7 }

frsldPvcHCOctetDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataHCDataDeliveredC,
frsldPvcDataHCDataDeliveredE,
frsldPvcDataHCDataOfferedC,
frsldPvcDataHCDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity octet data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 8 }

frsldPvcSampleDelayGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplDelayMin,
frsldPvcSmplDelayMax,
frsldPvcSmplDelayAvg,
frsldPvcSmplMissedPolls
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
sample data collected on a PVC which implements
Service Level Definitions.

If this group is implemented, frsldPvcDelayCtrlGroup
MUST also be implemented."
::= { frsldMIBGroups 9 }

frsldPvcSampleDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplFrDeliveredC,
frsldPvcSmplFrDeliveredE,

Steinberger & Nicklass Standards Track [Page 58]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

be supplemented by configuration. For example, the Node-ID and IP
address could be configured.

The adjacency table MAY contain information about the validity and
trust of the adjacent ACP node's certificate. However, subsequent
steps MUST always start with authenticating the peer.

The adjacency table contains information about adjacent ACP nodes in
general, independently of their domain and trust status. The next
step determines to which of those ACP nodes an ACP connection should
be established.

6.3. Neighbor Discovery with DULL GRASP

[RFC Editor: GRASP draft is in RFC editor queue, waiting for
dependencies, including ACP. Please ensure that references to I-
D.ietf-anima-grasp that include section number references (throughout
this document) will be updated in case any last-minute changes in
GRASP would make those section references change.

DULL GRASP is a limited subset of GRASP intended to operate across an
insecure link-local scope. See section 2.5.2 of
[I-D.ietf-anima-grasp] for its formal definition. The ACP uses one
instance of DULL GRASP for every L2 interface of the ACP node to
discover link level adjacent candidate ACP neighbors. Unless
modified by policy as noted earlier (Section 5 bullet point 2.),
native interfaces (e.g., physical interfaces on physical nodes)
SHOULD be initialized automatically to a state in which ACP discovery
can be performed and any native interfaces with ACP neighbors can
then be brought into the ACP even if the interface is otherwise not
configured. Reception of packets on such otherwise not configured
interfaces MUST be limited so that at first only IPv6 StateLess
Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work
and then only the following ACP secure channel setup packets - but
not any other unnecessary traffic (e.g., no other link-local IPv6
transport stack responders for example).

Note that the use of the IPv6 link-local multicast address
(ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
receive packets for that address. Otherwise DULL GRASP could fail to
operate correctly in the presence of MLD snooping, non-ACP enabled L2
switches - because those would stop forwarding DULL GRASP packets.
Switches not supporting MLD snooping simply need to operate as pure
L2 bridges for IPv6 multicast packets for DULL GRASP to work.

ACP discovery SHOULD NOT be enabled by default on non-native
interfaces. In particular, ACP discovery MUST NOT run inside the ACP

Eckert, et al. Expires February 8, 2019 [Page 30]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

across ACP virtual interfaces. See Section 10.3 for further, non-
normative suggestions on how to enable/disable ACP at node and
interface level. See Section 8.2.2 for more details about tunnels
(typical non-native interfaces). See Section 7 for how ACP should be
extended on devices operating (also) as L2 bridges.

Note: If an ACP node also implements BRSKI to enroll its ACP domain
certificate (see Appendix A.2 for a summary), then the above
considerations also apply to GRASP discovery for BRSKI. Each DULL
instance of GRASP set up for ACP is then also used for the discovery
of a bootstrap proxy via BRSKI when the node does not have a domain
certificate. Discovery of ACP neighbors happens only when the node
does have the certificate. The node therefore never needs to
discover both a bootstrap proxy and ACP neighbor at the same time.

An ACP node announces itself to potential ACP peers by use of the
"AN_ACP" objective. This is a synchronization objective intended to
be flooded on a single link using the GRASP Flood Synchronization
(M_FLOOD) message. In accordance with the design of the Flood
message, a locator consisting of a specific link-local IP address, IP
protocol number and port number will be distributed with the flooded
objective. An example of the message is informally:

[M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000,
["AN_ACP", 4, 1, "IKEv2" ],
[O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 15000]
["AN_ACP", 4, 1, "DTLS" ],
[O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 17000]
]

Figure 5: GRASP AN_ACP example

The formal CDDL definition is:

Eckert, et al. Expires February 8, 2019 [Page 31]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]

objective = ["AN_ACP", objective-flags, loop-count,
objective-value]

objective-flags = sync-only ; as in the GRASP specification
sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation
objective-value = method
method = "IKEv2" / "DTLS" ; or future standard methods

Figure 6: GRASP AN_ACP definition

The objective-flags field is set to indicate synchronization.

The loop-count is fixed at 1 since this is a link-local operation.

In the above example the RECOMMENDED period of sending of the
objective is 60 seconds. The indicated ttl of 210000 msec means that
the objective would be cached by ACP nodes even when two out of three
messages are dropped in transit.

The session-id is a random number used for loop prevention
(distinguishing a message from a prior instance of the same message).
In DULL this field is irrelevant but must still be set according to
the GRASP specification.

The originator MUST be the IPv6 link local address of the originating
ACP node on the sending interface.

The 'objective-value' parameter is a string indicating the secure
channel protocol available at the specified or implied locator.

The locator-option is optional and only required when the secure
channel protocol is not offered at a well-defined port number, or if
there is no well-defined port number.

"IKEv2" is the abbreviation for "Internet Key Exchange protocol
version 2", as defined in [RFC7296]. It is the main protocol used by
the Internet IP security architecture (IPsec). We therefore use the
term "IKEv2" and not "IPsec" in the GRASP definitions and example
above. "IKEv2" has a well-defined port number 500, but in the above
example, the candidate ACP neighbor is offering ACP secure channel
negotiation via IKEv2 on port 15000 (for the sake of creating a non-
standard example).

Eckert, et al. Expires February 8, 2019 [Page 32]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

"DTLS" indicates datagram Transport Layer Security version 1.2.
There is no default UDP port, it must always be locally assigned by
the node. See Section 6.7.2.

If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6
address MUST be the same as the initiator address (these are DULL
requirements to minimize third party DoS attacks).

The secure channel methods defined in this document use the objective
values of "IKEv2" and "DTLS". There is no distinction between IKEv2
native and GRE-IKEv2 because this is purely negotiated via IKEv2.

A node that supports more than one secure channel protocol method
needs to flood multiple versions of the "AN_ACP" objective so that
each method can be accompanied by its own locator-option. This can
use a single GRASP M_FLOOD message as shown in Figure 5.

Note that a node serving both as an ACP node and BRSKI Join Proxy may
choose to distribute the "AN_ACP" objective and the respective BRSKI
in the same M_FLOOD message, since GRASP allows multiple objectives
in one message. This may be impractical though if ACP and BRSKI
operations are implemented via separate software modules / ASAs.

The result of the discovery is the IPv6 link-local address of the
neighbor as well as its supported secure channel protocols (and non-
standard port they are running on). It is stored in the ACP
Adjacency Table, see Section 6.2 which then drives the further
building of the ACP to that neighbor.

6.4. Candidate ACP Neighbor Selection

An ACP node must determine to which other ACP nodes in the adjacency
table it should build an ACP connection. This is based on the
information in the ACP Adjacency table.

The ACP is established exclusively between nodes in the same domain.
This includes all routing subdomains. Appendix A.7 explains how ACP
connections across multiple routing subdomains are special.

The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel
establishment.

Eckert, et al. Expires February 8, 2019 [Page 33]
Internet-Draft An Autonomic Control Plane (ACP) August 2018

RFC 3202 Frame Relay Service Level Defs MIB January 2002

frsldPvcSmplFrOfferedC,
frsldPvcSmplFrOfferedE,
frsldPvcSmplDataDeliveredC,
frsldPvcSmplDataDeliveredE,
frsldPvcSmplDataOfferedC,
frsldPvcSmplDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing data
and frame delivery sample data collected on a PVC
which implements Service Level Definitions.

If this group is implemented, frsldPvcReqDataGroup
MUST also be implemented."
::= { frsldMIBGroups 10 }

frsldPvcSampleHCFrameGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplHCFrDeliveredC,
frsldPvcSmplHCFrDeliveredE,
frsldPvcSmplHCFrOfferedC,
frsldPvcSmplHCFrOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity frame delivery sample data collected on a PVC
which implements Service Level Definitions.

If this group is implemented, frsldPvcHCFrameDataGroup
MUST also be implemented."
::= { frsldMIBGroups 11 }

frsldPvcSampleHCDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplHCDataDeliveredC,
frsldPvcSmplHCDataDeliveredE,
frsldPvcSmplHCDataOfferedC,
frsldPvcSmplHCDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity data delivery sample data collected on a PVC
which implements Service Level Definitions.

If this group is implemented, frsldPvcHCOctetDataGroup

Steinberger & Nicklass Standards Track [Page 59]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

MUST also be implemented."
::= { frsldMIBGroups 12 }

frsldPvcSampleAvailGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplUnavailableTime,
frsldPvcSmplUnavailables
}
STATUS current
DESCRIPTION
"A collection of optional objects providing
availability sample data collected on a PVC which
implements Service Level Definitions.

If this group is implemented, frsldPvcReqDataGroup
MUST also be implemented."
::= { frsldMIBGroups 13 }

frsldPvcSampleGeneralGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplStartTime,
frsldPvcSmplEndTime
}
STATUS current
DESCRIPTION
"A collection of optional objects providing
general sample data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 14 }

frsldCapabilitiesGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlWriteCaps,
frsldSmplCtrlWriteCaps,
frsldRPCaps,
frsldMaxPvcCtrls,
frsldNumPvcCtrls,
frsldMaxSmplCtrls,
frsldNumSmplCtrls
}
STATUS current
DESCRIPTION
"A collection of required objects providing
capability information and control for this
MIB module."
::= { frsldMIBGroups 15 }
END

Steinberger & Nicklass Standards Track [Page 60]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

8. Acknowledgments

This document was produced by the Frame Relay Service MIB Working
Group. It is based on the Frame Relay Forum's implementation
agreement on service level definitions, FRF.13 [17].

The editors would like to thank the following people for their
helpful comments:

o Ken Rehbehn, Visual Networks

o Santa Dasu, Quick Eagle Networks

9. References

[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.

[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.

[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.

[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.

[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.

[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.

[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.

Steinberger & Nicklass Standards Track [Page 61]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.

[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.

[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.

[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.

[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.

[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.

[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.

[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.

[17] Frame Relay Forum Technical Committee, "Service Level
Definitions Implementations Agreement", FRF.13, August 1998.

[18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for
Frame Relay Service", RFC 2954, October 2000.

[19] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, January 1997.

[20] Brown, C. and F. Baker, "Management Information Base for Frame
Relay DTEs Using SMIv2", RFC 2115, September 1997.

[21] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.

[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

Steinberger & Nicklass Standards Track [Page 62]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

10. Security Considerations

There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.

SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.

It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [12] and the View-based
Access Control Model RFC 2575 [15] is recommended.

It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.

11. Authors' Addresses

Robert Steinberger
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, TX 75082

Phone: 1-972-479-4739
EMail: robert.steinberger@fnc.fujitsu.com

Orly Nicklass, Ph.D
RAD Data Communications Ltd.
12 Hanechoshet Street
Tel Aviv, Israel 69710

Phone: 972 3 7659969
EMail: Orly_n@rad.co.il

Steinberger & Nicklass Standards Track [Page 63]
RFC 3202 Frame Relay Service Level Defs MIB January 2002

12. Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Steinberger & Nicklass Standards Track [Page 64]

Definitions of Managed Objects for Frame Relay Service Level Definitions RFC 3202

Definitions of Managed Objects for Frame Relay Service Level Definitions
RFC 3202