2.2. Syslog Protocol
Syslog is a mechanism for distribution of logging information
initially used on Unix systems (see [RFC3164] for BSD syslog). The
IETF Syslog Protocol [RFC5424] introduces a layered architecture
allowing the use of any number of transport protocols, including
reliable and secure transports, for transmission of syslog messages.
The Syslog protocol enables a machine to send system log messages
across networks to event message collectors. The protocol is simply
designed to transport and distribute these event messages. By
default, no acknowledgements of the receipt are made, except the
reliable delivery extensions specified in [RFC3195] are used. The
Syslog protocol and process does not require a stringent coordination
between the transport sender and the receiver. Indeed, the
transmission of syslog messages may be started on a device without a
receiver being configured, or even actually physically present.
Conversely, many devices will most likely be able to receive messages
without explicit configuration or definitions.
BSD syslog had little uniformity for the message format and the
content of syslog messages. The body of a BSD syslog message has
traditionally been unstructured text. This content is human
friendly, but difficult to parse for applications. With the Syslog
Protocol [RFC5424], the IETF has standardized a new message header
format, including timestamp, hostname, application, and message ID,
to improve filtering, interoperability, and correlation between
The Syslog protocol [RFC5424] also introduces a mechanism for
defining Structured Data Elements (SDEs). The SDEs allow vendors to
define their own structured data elements to supplement standardized
elements. [RFC5675] defines a mapping from SNMP notifications to
syslog messages. [RFC5676] defines an SNMP MIB module to represent
syslog messages for the purpose of sending those syslog messages as
notifications to SNMP notification receivers. [RFC5674] defines the
way alarms are sent in syslog, which includes the mapping of ITU-
perceived severities onto syslog message fields and a number of
alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF
Alarm MIB [RFC3877].
"Signed Syslog Messages" [RFC5848] defines a mechanism to add origin
authentication, message integrity, replay resistance, message
sequencing, and detection of missing messages to the transmitted
syslog messages to be used in conjunction with the Syslog protocol.
The Syslog protocol's layered architecture provides support for a
number of transport mappings. For interoperability purposes and
especially in managed networks, where the network path has been
explicitly provisioned for UDP syslog traffic, the Syslog protocol
can be used over UDP [RFC5426]. However, to support congestion
control and reliability, [RFC5426] strongly recommends the use of the
Furthermore, the IETF defined the TLS Transport Mapping for syslog in
[RFC5425], which provides a secure connection for the transport of
syslog messages. [RFC5425] describes the security threats to syslog
and how TLS can be used to counter such threats. [RFC6012] defines
the Datagram Transport Layer Security (DTLS) Transport Mapping for
syslog, which can be used if a connectionless transport is desired.
For information on MIB modules related to syslog, see Section 4.2.1.
2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP)
"Specification of the IP Flow Information Export (IPFIX) Protocol for
the Exchange of IP Traffic Flow Information" (the IPFIX Protocol)
[RFC5101] defines a push-based data export mechanism for transferring
IP flow information in a compact binary format from an Exporter to a
"Architecture for IP Flow Information Export" (the IPFIX
Architecture) [RFC5470] defines the components involved in IP flow
measurement and reporting of information on IP flows, particularly, a
Metering Process generating Flow Records, an Exporting Process that
sends metered flow information using the IPFIX protocol, and a
Collecting Process that receives flow information as IPFIX Data
After listing the IPFIX requirements in [RFC3917], NetFlow Version 9
[RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX
IPFIX can run over different transport protocols. The IPFIX Protocol
[RFC5101] specifies Stream Control Transmission Protocol (SCTP)
[RFC4960] as the mandatory transport protocol to implement. Optional
alternatives are TCP [STD07] and UDP [STD06].
SCTP is used with its Partial Reliability extension (PR-SCTP)
specified in [RFC3758]. [RFC6526] specifies an extension to
[RFC5101], when using the PR-SCTP [RFC3758]. The extension offers
several advantages over IPFIX export, e.g., the ability to calculate
Data Record losses for PR-SCTP, immediate reuse of Template IDs
within an SCTP stream, reduced likelihood of Data Record loss, and
reduced demands on the Collecting Process.
IPFIX transmits IP flow information in Data Records containing IPFIX
Information Elements (IEs) defined by the IPFIX Information Model
[RFC5102]. IPFIX IEs are quantities with unit and semantics defined
by the Information Model. When transmitted over the IPFIX protocol,
only their values need to be carried in Data Records. This compact
encoding allows efficient transport of large numbers of measured flow
values. Remaining redundancy in Data Records can be further reduced
by the methods described in [RFC5473] (for further discussion on
IPFIX IEs, see Section 4).
The IPFIX Information Model is extensible. New IEs can be registered
at IANA (see "IPFIX Information Elements" in [IANA-PROT]). IPFIX
also supports the use of proprietary, i.e., enterprise-specific IEs.
The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of
transferring information on individual packets. [RFC5475] specifies
a set of sampling and filtering techniques for IP packet selection,
based on the PSAMP Framework [RFC5474]. The PSAMP Information Model
[RFC5477] provides a set of basic IEs for reporting packet
information with the IPFIX/PSAMP protocol.
The IPFIX model of an IP traffic flow is unidirectional. [RFC5103]
adds means of reporting bidirectional flows to IPFIX, for example,
both directions of packet flows of a TCP connection.
When enterprise-specific IEs are transmitted with IPFIX, a Collector
receiving Data Records may not know the type of received data and
cannot choose the right format for storing the contained information.
[RFC5610] provides a means of exporting extended type information for
enterprise-specific Information Elements from an Exporter to a
Collectors may store received flow information in files. The IPFIX
file format [RFC5655] can be used for storing IP flow information in
a way that facilitates exchange of traffic flow information between
different systems and applications.
In terms of IPFIX and PSAMP configurations, the Metering and
Exporting Processes are configured out of band. As the IPFIX
protocol is a push mechanism only, IPFIX cannot configure the
Exporter. The actual configuration of selection processes, caches,
Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-
compliant monitoring devices is executed using the NETCONF protocol
[RFC6241] (see Section 2.4.1). The "Configuration Data Model for
IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL]
has been specified using Unified Modeling Language (UML) class
diagrams. The data model is formally defined using the YANG modeling
language [RFC6020] (see Section 2.4.2).
At the time of this writing, a framework for IPFIX flow mediation is
in preparation, which addresses the need for mediation of flow
information in IPFIX applications in large operator networks, e.g.,
for aggregating huge amounts of flow data and for anonymization of
flow information (see the problem statement in [RFC5982]).
The IPFIX Mediation Framework [RFC6183] defines the intermediate
device between Exporters and Collectors, which provides an IPFIX
mediation by receiving a record stream from, e.g., a Collecting
Process, hosting one or more Intermediate Processes to transform this
stream, and exporting the transformed record stream into IPFIX
messages via an Exporting Process.
Examples for mediation functions are flow aggregation, flow
selection, and anonymization of traffic information (see [RFC6235]).
Privacy, integrity, and authentication of the Exporter and Collector
are important security requirements for IPFIX [RFC3917].
Confidentiality, integrity, and authenticity of IPFIX data
transferred from an Exporting Process to a Collecting Process must be
ensured. The IPFIX and PSAMP protocols do not define any new
security mechanisms and rely on the security mechanism of the
underlying transport protocol, such as TLS [RFC5246] and DTLS
The primary goal of IPFIX is the reporting of the flow accounting for
flexible flow definitions and usage-based accounting. As described
in the IPFIX Applicability Statement [RFC5472], there are also other
applications such as traffic profiling, traffic engineering,
intrusion detection, and QoS monitoring, that require flow-based
traffic measurements and can be realized using IPFIX. Furthermore,
the IPFIX Applicability Statement explains the relation of IPFIX to
other framework and protocols such as PSAMP, RMON (Remote Network
Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics,
Section 3.4)). Similar flow information could be also used for
security monitoring. The addition of Performance Metrics in the
IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to
Note that even if the initial IPFIX focus has been around IP flow
information exchange, non-IP-related IEs are now specified in the
IPFIX IANA registration (e.g., MAC (Media Access Control) address,
MPLS (Multiprotocol Label Switching) labels, etc.). At the time of
this writing, there are requests to widen the focus of IPFIX and to
export non-IP related IEs (such as SIP monitoring IEs).
The IPFIX structured data [RFC6313] is an extension to the IPFIX
protocol, which supports hierarchical structured data and lists
(sequences) of Information Elements in Data Records. This extension
allows the definition of complex data structures such as variable-
length lists and specification of hierarchical containment
relationships between templates. Furthermore, the extension provides
the semantics to express the relationship among multiple list
elements in a structured Data Record.
For information on data models related to the management of the IPFIX
and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For information
on IPFIX/PSAMP IEs, see Section 4.2.3.
2.4. Network Configuration
2.4.1. Network Configuration Protocol (NETCONF)
The IAB workshop on Network Management [RFC3535] determined advanced
requirements for configuration management:
o robustness: Minimizing disruptions and maximizing stability,
o a task-oriented view,
o extensibility for new operations,
o standardized error handling,
o clear distinction between configuration data and operational
o distribution of configurations to devices under transactional
o single- and multi-system transactions and scalability in the
number of transactions and managed devices,
o operations on selected subsets of management data,
o dumping and reloading a device configuration in a textual format
in a standard manner across multiple vendors and device types,
o a human interface and a programmatic interface,
o a data modeling language with a human-friendly syntax,
o easy conflict detection and configuration validation, and
o secure transport, authentication, and robust access control.
The NETCONF protocol [RFC6241] provides mechanisms to install,
manipulate, and delete the configuration of network devices and aims
to address the configuration management requirements pointed out in
the IAB workshop. It uses an XML-based data encoding for the
configuration data as well as the protocol messages. The NETCONF
protocol operations are realized on top of a simple and reliable
Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that
it allows the functionality of the management protocol to closely
mirror the native command-line interface of the device.
The NETCONF working group developed the NETCONF Event Notifications
Mechanism as an optional capability, which provides an asynchronous
message notification delivery service for NETCONF [RFC5277]. The
NETCONF notification mechanism enables using general purpose
notification streams, where the originator of the notification stream
can be any managed device (e.g., SNMP notifications).
The NETCONF Partial Locking specification introduces fine-grained
locking of the configuration datastore to enhance NETCONF for fine-
grained transactions on parts of the datastore [RFC5717].
The NETCONF working group also defined the necessary data model to
monitor the NETCONF protocol [RFC6022], by using the modeling
language YANG [RFC6020] (see Section 2.4.2). The monitoring data
model includes information about NETCONF datastores, sessions, locks,
and statistics, which facilitate the management of a NETCONF server.
NETCONF connections are required to provide authentication, data
integrity, confidentiality, and replay protection. NETCONF depends
on the underlying transport protocol for this capability. For
example, connections can be encrypted in TLS or SSH, depending on the
The NETCONF working group defined the SSH transport protocol as the
mandatory transport binding [RFC6242]. Other optional transport
bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol
(BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP)
over HTTP over TLS [RFC4743].
The NETCONF Access Control Model (NACM) [RFC6536] provides standard
mechanisms to restrict protocol access to particular users with a
pre-configured subset of operations and content.
2.4.2. YANG - NETCONF Data Modeling Language
Following the guidelines of the IAB management workshop [RFC3535],
the NETMOD working group developed a data modeling language defining
the semantics of operational and configuration data, notifications,
and operations [RFC6020]. The new data modeling language, called
YANG, maps directly to XML-encoded content (on the wire) and will
serve as the normative description of NETCONF data models.
YANG has the following properties addressing specific requirements on
a modeling language for configuration management:
o YANG provides the means to define hierarchical data models. It
supports reusable data types and groupings, i.e., a set of schema
nodes that can be reused across module boundaries.
o YANG supports the distinction between configuration and state
data. In addition, it provides support for modeling event
notifications and the specification of operations that extend the
base NETCONF operations.
o YANG allows the expression of constraints on data models by means
of type restrictions and XML Path Language (XPATH) 1.0 [XPATH]
expressions. XPATH expressions can also be used to make certain
portions of a data model conditional.
o YANG supports the integration of standard- and vendor-defined data
models. YANG's augmentation mechanism allows the seamless
augmentation of standard data models with proprietary extensions.
o YANG data models can be partitioned into collections of features,
allowing low-end devices only to implement the core features of a
data model while high-end devices may choose to support all
features. The supported features are announced via the NETCONF
capability exchange to management applications.
o The syntax of the YANG language is compact and optimized for human
readers. An associated XML-based syntax called the YANG
Independent Notation (YIN) [RFC6020] is available to allow the
processing of YANG data models with XML-based tools. The mapping
rules for the translation of YANG data models into Document Schema
Definition Languages (DSDL), of which RELAX NG is a major
component, are defined in [RFC6110].
o Devices implementing standard data models can document deviations
from the data model in separate YANG modules. Applications
capable of discovering deviations can make allowances that would
otherwise not be possible.
A collection of common data types for IETF-related standards is
provided in [RFC6021]. This standard data type library has been
derived to a large extend from common SMIv2 data types, generalizing
them to a less-constrained NETCONF Framework.
The document "An Architecture for Network Management using NETCONF
and YANG" describes how NETCONF and YANG can be used to build network
management applications that meet the needs of network operators
The Experimental RFC [RFC6095] specifies extensions for YANG,
introducing language abstractions such as class inheritance and
recursive data structures.
[RFC6087] gives guidelines for the use of YANG within the IETF and
other standardization organizations.
Work is underway to standardize a translation of SMIv2 data models
into YANG data models preserving investments into SNMP MIB modules,
which are widely available for monitoring purposes [SMI-YANG].
Several independent and open source implementations of the YANG data
modeling language and associated tools are available.
While YANG is a relatively recent data modeling language, some data
models have already been produced. The specification of the base
NETCONF protocol operations has been revised and uses YANG as the
normative modeling language to specify its operations [RFC6241]. The
IPFIX working group prepared the normative model for configuring and
monitoring IPFIX- and PSAMP-compliant monitoring devices using the
YANG modeling language [CONF-MODEL].
At the time of this writing, the NETMOD working group is developing
core system and interface data models. Following the example of the
IPFIX configuration model, IETF working groups will prepare models
for their specific needs.
For information on data models developed using the YANG modeling
language, see Sections 4.2.1 and 4.2.2.
3. Network Management Protocols and Mechanisms with Specific Focus
This section reviews additional protocols the IETF offers for
management and discusses for which applications they were designed
and/or have already been successfully deployed. These are protocols
that have mostly reached Proposed Standard status or higher within
3.1. IP Address Management
3.1.1. Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
framework for passing configuration information to hosts on a TCP/IP
network and, as such, enables autoconfiguration in IP networks. In
addition to IP address management, DHCP can also provide other
configuration information, such as default routers, the IP addresses
of recursive DNS servers, and the IP addresses of NTP servers. As
described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address
Allocation and Assignment as well as for Service Discovery.
There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and
one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension
to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently
defined to accommodate new functions required by IPv6 such as
assignment of multiple addresses to an interface and to address
limitations in the design of DHCPv4 resulting from its origins in
BOOTP. While both versions bear the same name and perform the same
functionality, the details of DHCPv4 and DHCPv6 are sufficiently
different that they can be considered separate protocols.
In addition to the assignment of IP addresses and other configuration
information, DHCP options like the Relay Agent Information option
(DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315]
are widely used by ISPs.
DHCPv6 includes Prefix Delegation [RFC3633], which is used to
provision a router with an IPv6 prefix for use in the subnetwork
supported by the router.
The following are examples of DHCP options that provide configuration
information or access to specific servers. A complete list of DHCP
options is available at [IANA-PROT].
o "DNS Configuration options for Dynamic Host Configuration Protocol
for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing
a list of available DNS recursive name servers and a domain search
list to a client.
o "DHCP Options for Service Location Protocol" [RFC2610] describes
DHCPv4 options and methods through which entities using the
Service Location Protocol can find out the address of Directory
Agents in order to transact messages and how the assignment of
scope for configuration of Service Location Protocol (SLP) User
and Service Agents can be achieved.
o "Dynamic Host Configuration Protocol (DHCPv6) Options for Session
Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6
options that allow SIP clients to locate a local SIP server that
is to be used for all outbound SIP requests, a so-called "outbound
o "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast
and Multicast Control Servers" [RFC4280] defines DHCPv6 options to
discover the Broadcast and Multicast Service (BCMCS) controller in
an IP network.
Built directly on UDP and IP, DHCP itself has no security provisions.
There are two different classes of potential security issues related
to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients.
The recommended solutions to these risks generally involve providing
security at lower layers, e.g., careful control over physical access
to the network, security techniques implemented at Layer 2 but also
IPsec at Layer 3 can be used to provide authentication.
3.1.2. Ad Hoc Network Autoconfiguration
Ad hoc nodes need to configure their network interfaces with locally
unique addresses as well as globally routable IPv6 addresses, in
order to communicate with devices on the Internet. The IETF AUTOCONF
working group developed [RFC5889], which describes the addressing
model for ad hoc networks and how nodes in these networks configure
The ad hoc nodes under consideration are expected to be able to
support multi-hop communication by running MANET (Mobile Ad Hoc
Network) routing protocols as developed by the IETF MANET working
From the IP layer perspective, an ad hoc network presents itself as a
Layer 3 multi-hop network formed over a collection of links. The
addressing model aims to avoid problems for parts of the system that
are ad hoc unaware, such as standard applications running on an ad
hoc node or regular Internet nodes attached to the ad hoc nodes.
3.2. IPv6 Network Operations
The IPv6 Operations (V6OPS) working group develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks, as
well as into new network installations.
o "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213]
specifies IPv4 compatibility mechanisms for dual-stack and
configured tunneling that can be implemented by IPv6 hosts and
routers. "Dual stack" implies providing complete implementations
of both IPv4 and IPv6, and configured tunneling provides a means
to carry IPv6 packets over unmodified IPv4 routing
o "Transition Scenarios for 3GPP Networks" [RFC3574] lists different
scenarios in 3GPP defined packet network that would need IPv6 and
IPv4 transition, where "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks" [RFC4215] does a
more detailed analysis of the transition scenarios that may come
up in the deployment phase of IPv6 in 3GPP packet networks.
o "Scenarios and Analysis for Introducing IPv6 into ISP Networks"
[RFC4029] describes and analyzes different scenarios for the
introduction of IPv6 into an ISP's existing IPv4 network. "IPv6
Deployment Scenarios in 802.16 Networks" [RFC5181] provides a
detailed description of IPv6 deployment, integration methods, and
scenarios in wireless broadband access networks (802.16) in
coexistence with deployed IPv4 services. [RFC4057] describes the
scenarios for IPv6 deployment within enterprise networks.
o "Application Aspects of IPv6 Transition" [RFC4038] specifies
scenarios and application aspects of IPv6 transition considering
how to enable IPv6 support in applications running on IPv6 hosts,
and giving guidance for the development of IP-version-independent
o "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598]
updates RFC 5735 and requested the allocation of an IPv4/10
address block to be used as "Shared Carrier-Grade Network Address
Translation (CGN) Space" by Service Providers to number the
interfaces that connect CGN devices to Customer Premises Equipment
3.3. Policy-Based Management
3.3.1. IETF Policy Framework
The IETF specified a general policy framework [RFC2753] for managing,
sharing, and reusing policies in a vendor-independent, interoperable,
and scalable manner. [RFC3460] specifies the Policy Core Information
Model (PCIM) as an object-oriented information model for representing
policy information. PCIM has been developed jointly in the IETF
Policy Framework (POLICY) working group and the Common Information
Model (CIM) activity in the Distributed Management Task Force (DMTF).
PCIM has been published as extensions to CIM [DMTF-CIM].
The IETF Policy Framework is based on a policy-based admission
control specifying two main architectural elements: the Policy
Enforcement Point (PEP) and the Policy Decision Point (PDP). For the
purpose of network management, policies allow an operator to specify
how the network is to be configured and monitored by using a
descriptive language. Furthermore, it allows the automation of a
number of management tasks, according to the requirements set out in
the policy module.
The IETF Policy Framework has been accepted by the industry as a
standard-based policy management approach and has been adopted by
different SDOs, e.g., for 3GGP charging standards.
3.3.2. Use of Common Open Policy Service (COPS) for Policy Provisioning
[RFC3159] defines the Structure of Policy Provisioning Information
(SPPI), an extension to the SMIv2 modeling language used to write
Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the
Common Open Policy Service (COPS) protocol [RFC2748] for the
provisioning of policy information. COPS provides a simple client/
server model for supporting policy control over QoS signaling
protocols. The COPS-PR specification is independent of the type of
policy being provisioned (QoS, security, etc.) but focuses on the
mechanisms and conventions used to communicate provisioned
information between policy-decision-points (PDPs) and policy
enforcement points (PEPs). Policy data is modeled using PIB modules.
COPS-PR has not been widely deployed, and operators have stated that
its use of binary encoding for management data makes it difficult to
develop automated scripts for simple configuration management tasks
in most text-based scripting languages. In the IAB Workshop on
Network Management [RFC3535], the consensus of operators and protocol
developers indicated a lack of interest in PIB modules for use with
As a result, even if COPS-PR and the Structure of Policy Provisioning
Information (SPPI) were initially approved as Proposed Standards, the
IESG has not approved any PIB modules as Proposed Standard, and the
use of COPS-PR is not recommended.
3.4. IP Performance Metrics (IPPM)
The IPPM working group has defined metrics for accurately measuring
and reporting the quality, performance, and reliability of Internet
data delivery. The metrics include connectivity, one-way delay and
loss, round-trip delay and loss, delay variation, loss patterns,
packet reordering, bulk transport capacity, and link bandwidth
These metrics are designed for use by network operators and their
customers, and they provide unbiased quantitative measures of
performance. The IPPM metrics have been developed inside an active
measurement context, that is, the devices used to measure the metrics
produce their own traffic. However, most of the metrics can be used
inside a passive context as well. At the time of this writing, there
is no work planned in the area of passive measurement.
As a property, individual IPPM performance and reliability metrics
need to be well defined and concrete: thus, implementable.
Furthermore, the methodology used to implement a metric needs to be
repeatable with consistent measurements.
IPPMs have been adopted by different organizations, e.g., the Metro
Note that this document does not aim to cover OAM technologies on the
data-path and, as such, the discussion of IPPM-based active versus
passive monitoring as well as the data plane measurement and its
diagnostics is rather incomplete. For a detailed overview and
discussion of IETF OAM standards and IPPM measurement mechanisms, the
reader is referred to the documents listed at the end of Section 1.2
("Related Work") but especially to [OAM-OVERVIEW].
The following are essential IPPM documents:
o "Framework for IP Performance Metrics" [RFC2330] defines a general
framework for particular metrics developed by the IPPM working
group, and it defines the fundamental concepts of 'metric' and
'measurement methodology'. It also discusses the issue of
measurement uncertainties and errors as well as introduces the
notion of empirically defined metrics and how metrics can be
o "A One-way Delay Metric for IPPM" [RFC2679] defines a metric for
the one-way delay of packets across Internet paths. It builds on
notions introduced in the IPPM Framework document.
o "A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric
for the round-trip delay of packets across network paths and
closely follows the corresponding metric for one-way delay.
o "IP Packet Delay Variation Metric for IP Performance Metrics
(IPPM)" [RFC3393] refers to a metric for variation in the delay of
packets across network paths and is based on the difference in the
one-way-delay of selected packets called "IP Packet Delay
o "A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric
for one-way packet loss across Internet paths.
o "A One-Way Packet Duplication Metric" [RFC5560] defines a metric
for the case where multiple copies of a packet are received, and
it discusses methods to summarize the results of streams.
o "Packet Reordering Metrics" [RFC4737] defines metrics to evaluate
whether a network has maintained packet order on a packet-by-
packet basis and discusses the measurement issues, including the
context information required for all metrics.
o "IPPM Metrics for Measuring Connectivity" [RFC2678] defines a
series of metrics for connectivity between a pair of Internet
o "Framework for Metric Composition" [RFC5835] describes a detailed
framework for composing and aggregating metrics.
o "Guidelines for Considering New Performance Metric Development"
[BCP170] describes the framework and process for developing
Performance Metrics of protocols and applications transported over
To measure these metrics, two protocols and a sampling method have
o "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures
unidirectional characteristics such as one-way delay and one-way
loss between network devices and enables the interoperability of
these measurements. OWAMP is discussed in more detail in
o "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds
round-trip or two-way measurement capabilities to OWAMP. TWAMP is
discussed in more detail in [OAM-OVERVIEW].
o "Network performance measurement with periodic streams" [RFC3432]
describes a periodic sampling method and relevant metrics for
assessing the performance of IP networks, as an alternative to the
Poisson sampling method described in [RFC2330].
For information on MIB modules related to IP Performance Metrics see
3.5. Remote Authentication Dial-In User Service (RADIUS)
"Remote Authentication Dial In User Service (RADIUS)" [RFC2865]
describes a client/server protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server (NAS), which desires to authenticate its links, and a shared
authentication server. The companion document "Radius Accounting"
[RFC2866] describes a protocol for carrying accounting information
between a NAS and a shared accounting server. [RFC2867] adds
required new RADIUS accounting attributes and new values designed to
support the provision of tunneling in dial-up networks.
The RADIUS protocol is widely used in environments like enterprise
networks, where a single administrative authority manages the network
and protects the privacy of user information. RADIUS is deployed in
the networks of fixed broadband access provider as well as cellular
RADIUS uses attributes to carry the specific authentication,
authorization, information, and configuration details. RADIUS is
extensible with a known limitation of a maximum of 255 attribute
codes and 253 octets as attribute content length. RADIUS has Vendor-
Specific Attributes (VSAs), which have been used both for vendor-
specific purposes (as an addition to standardized attributes) as well
as to extend the limited attribute code space.
The RADIUS protocol uses a shared secret along with the MD5 hash
algorithm to secure passwords [RFC1321]. Based on the known threads,
additional protection like IPsec tunnels [RFC4301] are used to
further protect the RADIUS traffic. However, building and
administering large IPsec-protected networks may become a management
burden, especially when the IPsec-protected RADIUS infrastructure
should provide inter-provider connectivity. Moving towards TLS-based
security solutions [RFC5246] and establishing dynamic trust
relationships between RADIUS servers has become a trend. Since the
introduction of TCP transport for RADIUS [RFC6613], it became natural
to have TLS support for RADIUS. An ongoing work is "Transport Layer
Security (TLS) encryption for RADIUS" [RFC6614].
"RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a
number of RADIUS attributes designed to support the compulsory
provision of tunneling in dial-up network access. Some applications
involve compulsory tunneling, i.e., the tunnel is created without any
action from the user and without allowing the user any choice in the
matter. In order to provide this functionality, specific RADIUS
attributes are needed to carry the tunneling information from the
RADIUS server to the tunnel end points. "Signalling Connection
Control Part User Adaptation Layer (SUA)" [RFC3868] defines the
necessary attributes, attribute values, and the required IANA
"RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over
IPv6 and the RADIUS attributes used to support the IPv6 network
access. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes
how to transport delegated IPv6 prefix information over RADIUS.
"RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675]
defines additional attributes for dynamic Virtual LAN assignment and
prioritization, for use in provisioning of access to IEEE 802 local
area networks usable with RADIUS and diameter.
"Common Remote Authentication Dial In User Service (RADIUS)
Implementation Issues and Suggested Fixes" [RFC5080] describes common
issues seen in RADIUS implementations and suggests some fixes. Where
applicable, unclear statements and errors in previous RADIUS
specifications are clarified. People designing extensions to RADIUS
protocol for various deployment cases should get familiar with
"RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known
"RADIUS Extension for Digest Authentication" [RFC5090] defines an
extension to the RADIUS protocol to enable support of Digest
Authentication, for use with HTTP-style protocols like the Session
Initiation Protocol (SIP) and HTTP.
"Carrying Location Objects in RADIUS and DIAMETER" [RFC5580]
describes procedures for conveying access-network ownership and
location information based on civic and geospatial location formats
in RADIUS and diameter.
"Remote Authentication Dial-In User Service (RADIUS) Authorization
for Network Access Server (NAS) Management" [RFC5607] specifies
required RADIUS attributes and their values for authorizing a
management access to a NAS. Both local and remote management are
supported, with access rights and management privileges. Specific
provisions are made for remote management via Framed Management
protocols, such as SNMP and NETCONF, and for management access over a
secure transport protocol.
"RADIUS (Remote Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)" [RFC3579] describes how to
use RADIUS to convey an EAP [RFC3748] payload between the
authenticator and the EAP server using RADIUS. RFC 3579 is widely
implemented, for example, in WLAN and 802.1 X environments. "IEEE
802.1X Remote Authentication Dial In User Service (RADIUS) Usage
Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X
authenticators. In the context of 802.1X and EAP-based
authentication, the VSAs described in [RFC2458] have been widely
accepted by the industry. "RADIUS Extensions" [RFC2869] is another
important RFC related to EAP use. RFC 2869 describes additional
attributes for carrying AAA information between a NAS and a shared
accounting server using RADIUS. It also defines attributes to
encapsulate EAP message payload.
There are different MIB modules defined for multiple purposes to use
with RADIUS (see Sections 4.2.3 and 4.2.5).
3.6. Diameter Base Protocol (Diameter)
Diameter [RFC3588] provides an Authentication, Authorization, and
Accounting (AAA) framework for applications such as network access or
IP mobility. Diameter is also intended to work in local AAA and in
roaming scenarios. Diameter provides an upgrade path for RADIUS but
is not directly backwards compatible.
Diameter is designed to resolve a number of known problems with
RADIUS. Diameter supports server failover, reliable transport over
TCP and SCTP, well-documented functions for proxy, redirect and relay
agent functions, server-initiated messages, auditability, and
capability negotiation. Diameter also provides a larger attribute
space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS.
Diameter features make it especially appropriate for environments,
where the providers of services are in different administrative
domains than the maintainer (protector) of confidential user
Other notable differences to RADIUS are as follows:
o Network and Transport Layer Security (IPsec or TLS),
o Stateful and stateless models,
o Dynamic discovery of peers (using DNS Service Record (SRV) and
Naming Authority Pointer (NAPTR)),
o Concept of an application that describes how a specific set of
commands and Attribute-Value Pairs (AVPs) are treated by diameter
nodes. Each application has an IANA-assigned unique identifier,
o Support of application layer acknowledgements, failover methods
and state machines,
o Basic support for user-sessions and accounting,
o Better roaming support,
o Error notification, and
o Easy extensibility.
The Diameter protocol is designed to be extensible to support, e.g.,
proxies, brokers, mobility and roaming, Network Access Servers
(NASREQ), and Accounting and Resource Management. Diameter
applications extend the Diameter base protocol by adding new commands
and/or attributes. Each application is defined by a unique IANA-
assigned application identifier and can add new command codes and/or
new mandatory AVPs.
The Diameter application identifier space has been divided into
Standards Track and 'First Come First Served' vendor-specific
applications. The following are examples of Diameter applications
published at IETF:
o Diameter Base Protocol Application [RFC3588]: Required support
from all Diameter implementations.
o Diameter Base Accounting Application [RFC3588]: A Diameter
application using an accounting protocol based on a server-
directed model with capabilities for real-time delivery of
o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application
that allows a Diameter server to authenticate, authorize, and
collect accounting information for Mobile IPv4 services rendered
to a mobile node.
o Diameter Network Access Server Application (NASREQ, [RFC4005]): A
Diameter application used for AAA services in the NAS environment.
o Diameter Extensible Authentication Protocol Application [RFC4072]:
A Diameter application that carries EAP packets between a NAS and
a back-end authentication server.
o Diameter Credit-Control Application [RFC4006]: A Diameter
application that can be used to implement real-time credit-control
for a variety of end-user services such as network access, Session
Initiation Protocol (SIP) services, messaging services, and
o Diameter Session Initiation Protocol Application [RFC4740]: A
Diameter application designed to be used in conjunction with SIP
and provides a Diameter client co-located with a SIP server, with
the ability to request the authentication of users and
authorization of SIP resources usage from a Diameter server.
o Diameter Quality-of-Service Application [RFC5866]: A Diameter
application allowing network elements to interact with Diameter
servers when allocating QoS resources in the network.
o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter
application that enables the interaction between a Mobile IP home
agent and a Diameter server and is used when the mobile node is
authenticated and authorized using IKEv2 [RFC5996].
o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A
Diameter application that enables the interaction between a Mobile
IP home agent and a Diameter server and is used when the mobile
node is authenticated and authorized using the Mobile IPv6
Authentication Protocol [RFC4285].
The large majority of Diameter applications are vendor-specific and
mainly used in various SDOs outside the IETF. One example SDO using
diameter extensively is 3GPP (e.g., 3GPP 'IP Multimedia Subsystem'
(IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]).
Recently, during the standardization of the '3GPP Evolved Packet
Core' [3GPPEPC], diameter was chosen as the only AAA signaling
One part of diameter's extensibility mechanism is an easy and
consistent way of creating new commands for the need of applications.
RFC 3588 proposed to define diameter command code allocations with a
new RFC. This policy decision caused undesired use and redefinition
of existing command codes within SDOs. Diverse RFCs have been
published as simple command code allocations for other SDO purposes
(see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719]
changed the command code policy and added a range for vendor-specific
command codes to be allocated on a 'First Come First Served' basis by
The implementation and deployment experience of diameter has led to
the ongoing development of an update of the base protocol [DIAMETER],
which introduces TLS as the preferred security mechanism and
deprecates the in-band security negotiation for TLS.
Some Diameter protocol enhancements and clarifications that logically
fit better into [DIAMETER], are also needed on the existing
deployments based on RFC 3588. Therefore, protocol extensions
specifically usable in large inter-provider roaming network scenarios
are made available for RFC 3588. Two currently existing
specifications are mentioned below:
o "Clarifications on the Routing of Diameter Requests Based on the
Username and the Realm" [RFC5729] defines the behavior required
for Diameter agents to route requests when the User-Name AVP
contains a NAI formatted with multiple realms. These multi-realm
Network Access Identifiers are used in order to force the routing
of request messages through a predefined list of mediating realms.
o "Diameter Straightforward-Naming Authority Pointer (S-NAPTR)
Usage" [RFC6408] describes an improved DNS-based dynamic Diameter
agent discovery mechanism without having to do diameter capability
exchange beforehand with a number of agents.
There have been a growing number of Diameter Framework documents from
the IETF that basically are just a collection of AVPs for a specific
purpose or a system architecture with semantic AVP descriptions and a
logic for "imaginary" applications. From a standardization point of
view, this practice allows the development of larger system
architecture documents that do not need to reference AVPs or
application logic outside the IETF. Below are examples of a few
recent AVP and Framework documents:
o "Diameter Mobile IPv6: Support for Network Access Server to
Diameter Server Interaction" [RFC5447] describes the bootstrapping
of the Mobile IPv6 framework and the support of interworking with
existing AAA infrastructures by using the diameter NAS-to-home-AAA
o "Traffic Classification and Quality of Service (QoS) Attributes
for Diameter" [RFC5777] defines a number of Diameter AVPs for
traffic classification with actions for filtering and QoS
o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local
Mobility Anchor Interaction with Diameter Server" [RFC5779]
defines AAA interactions between Proxy Mobile IPv6 (PMIPv6)
entities (MAG and LMA) and a AAA server within a PMIPv6 Domain.
For information on MIB modules related to diameter, see
3.7. Control and Provisioning of Wireless Access Points (CAPWAP)
Wireless LAN (WLAN) product architectures have evolved from single
autonomous Access Points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility
management, and radio management from the single access point to a
centralized controller, where an Access Point pulls the information
from the AC.
Based on "Architecture Taxonomy for Control and Provisioning of
Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group
developed the CAPWAP protocol [RFC5415] to facilitate control,
management, and provisioning of WTPs specifying the services,
functions, and resources relating to 802.11 WLAN Termination Points
in order to allow for interoperable implementations of WTPs and ACs.
The protocol defines the CAPWAP control plane, including the
primitives to control data access. The protocol document also
specifies how configuration management of WTPs can be done and
defines CAPWAP operations responsible for debugging, gathering
statistics, logging, and managing firmware as well as discusses
operational and transport considerations.
The CAPWAP protocol is prepared to be independent of Layer 2
technologies, and meets the objectives in "Objectives for Control and
Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate
binding extensions enable the use with additional wireless
technologies. [RFC5416] defines the CAPWAP Protocol Binding for IEEE
CAPWAP Control messages, and optionally CAPWAP Data messages, are
secured using DTLS [RFC6347]. DTLS is used as a tightly integrated,
secure wrapper for the CAPWAP protocol.
For information on MIB modules related to CAPWAP, see Section 4.2.2.
3.8. Access Node Control Protocol (ANCP)
The Access Node Control Protocol (ANCP) [RFC6320] realizes a control
plane between a service-oriented Layer 3 edge device, the NAS and a
Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module
(DSLAM). As such, ANCP operates in a multi-service reference
architecture and communicates QoS-, service-, and subscriber-related
configuration and operation information between a NAS and an AN.
The main goal of this protocol is to configure and manage access
equipment and allow them to report information to the NAS in order to
enable and optimize configuration.
The framework and requirements for an AN control mechanism and the
use cases for ANCP are documented in [RFC5851].
ANCP offers authentication and authorization between AN and NAS nodes
and provides replay protection and data-origin authentication. The
ANCP solution is also robust against Denial-of-Service (DoS) attacks.
Furthermore, the ANCP solution is recommended to offer
confidentiality protection. Security Threats and Security
Requirements for ANCP are discussed in [RFC5713].
3.9. Application Configuration Access Protocol (ACAP)
The Application Configuration Access Protocol (ACAP) [RFC2244] is
designed to support remote storage and access of program option,
configuration, and preference information. The datastore model is
designed to allow a client relatively simple access to interesting
data, to allow new information to be easily added without server
reconfiguration, and to promote the use of both standardized data and
custom or proprietary data. Key features include "inheritance",
which can be used to manage default values for configuration settings
and access control lists that allow interesting personal information
to be shared and group information to be restricted.
ACAP's primary purpose is to allow applications access to their
configuration data from multiple network-connected computers. Users
can then use any network-connected computer, run any ACAP-enabled
application, and have access to their own configuration data. To
enable wide usage client simplicity has been preferred to server or
protocol simplicity whenever reasonable.
The ACAP 'authenticate' command uses Simple Authentication and
Security Layer (SASL) [RFC4422] to provide basic authentication,
authorization, integrity, and privacy services. All ACAP
implementations are required to implement the CRAM-MD5 (Challenge-
Response Authentication Mechanism) [RFC2195] for authentication,
which can be disabled based on the site security policy.
3.10. XML Configuration Access Protocol (XCAP)
The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) [RFC4825] has been designed for and is commonly used with SIP-
based solutions, in particular, for instant messages, presence, and
SIP conferences. XCAP is a protocol that allows a client to read,
write, and modify application configuration data stored in XML format
on a server, where the main functionality is provided by so-called
"XCAP Application Usages".
XCAP is a protocol that can be used to manipulate per-user data.
XCAP is a set of conventions for mapping XML documents and document
components into HTTP URIs, rules for how the modification of one
resource affects another, data validation constraints, and
authorization policies associated with access to those resources.
Because of this structure, normal HTTP primitives can be used to
manipulate the data. Like ACAP, XCAP supports the configuration
needs for a multiplicity of applications.
All XCAP servers are required to implement HTTP Digest Authentication
[RFC2617]. Furthermore, XCAP servers are required to implement HTTP
over TLS (HTTPS) [RFC2818]. It is recommended that administrators
use an HTTPS URI as the XCAP root URI, so that the digest client
authentication occurs over TLS.
The following list summarizes important XCAP application usages:
o XCAP server capabilities [RFC4825] can be read by clients to
determine which extensions, application usages, or namespaces a
o A resource lists application is any application that needs access
to a list of resources, identified by a URI, to which operations,
such as subscriptions, can be applied [RFC4826].
o A Resource List Server (RLS) Services application is a SIP
application, where a server receives SIP SUBSCRIBE requests for
resources and generates subscriptions towards the resource list
o A Presence Rules application uses authorization policies, also
known as authorization rules, to specify what presence information
can be given to which watchers, and when [RFC4827].
o A 'pidf-manipulation' application defines how XCAP is used to
manipulate the contents of PIDF-based presence documents