UDP-based Transport for Configured
SubscriptionsHuawei101 Yu-Hua-Tai Software RoadNanjingJiangsuChinazhengguangying@huawei.comHuawei156 Beiqing Rd., Haidian DistrictBeijingChinazhoutianran@huawei.comSwisscomBinzring 17Zuerich 8045Switzerlandthomas.graf@swisscom.comINSA-LyonLyonFrancepierre.francois@insa-lyon.frNTTSiriusdreef 70-72Hoofddorp, WT 2132NLpaolo@ntt.netNETCONFThis document describes an UDP-based notification mechanism to
collect data from networking devices. A shim header is proposed to
facilitate the data streaming directly from the publishing process on
network processor of line cards to receivers. The objective is a
lightweight approach to enable higher frequency and less performance
impact on publisher and receiver process compared to already established
notification mechanisms.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.Sub-Notif defines a mechanism that lets
a receiver subscribe to the publication of YANG-defined data maintained
in a YANG datastore. The mechanism
separates the management and control of subscriptions from the transport
used to deliver the data. Three transport mechanisms, namely NETCONF transport, RESTCONF transport, and HTTPS transport have been
defined so far for such notification messages.While powerful in their features and general in their architecture,
the currently available transport mechanisms need to be complemented to
support data publications at high velocity from devices that feature a
distributed architecture. The currently available transports are based
on TCP and lack the efficiency needed to continuously send notifications
at high velocity.This document specifies a transport option for Sub-Notif that
leverages UDP. Specifically, it facilitates the distributed data
collection mechanism described in . In the case of publishing
from multiple network processors on multiple line cards, centralized
designs require data to be internally forwarded from those network
processors to the push server, presumably on a route processor, which
then combines the individual data items into a single consolidated
stream. The centralized data collection mechanism can result in a
performance bottleneck, especially when large amounts of data are
involved.What is needed is a mechanism that allows for directly publishing
from multiple network processors on line cards, without passing them
through an additional processing stage for internal consolidation. The
proposed UDP-based transport allows for such a distributed data
publishing approach.Firstly, a UDP approach reduces the burden of maintaining a large
amount of active TCP connections at the receiver, notably in cases
where it collects data from network processors on line cards from a
large amount of networking devices.Secondly, as no connection state needs to be maintained, UDP
encapsulation can be easily implemented by the hardware of the
publication streamer, which will further improve performance.Ultimately, such advantages allow for a larger data analysis
feature set, as more voluminous, finer grained data sets can be
streamed to the receiver.The transport described in this document can be used for transmitting
notification messages over both IPv4 and IPv6.This document describes the notification mechanism. It is intended to
be used in conjunction with , extended by . describes the control of the proposed
transport mechanism. details the
notification mechanism and message format. discusses congestion control. covers the applicability of the proposed
mechanism.This section describes how the proposed mechanism can be controlled
using subscription channels based on NETCONF or RESTCONF.Following the usual approach of Sub-Notif, configured subscriptions
contain the location information of all the receivers, including the IP
address and the port number, so that the publisher can actively send
UDP-Notif messages to the corresponding receivers.Note that receivers MAY NOT be already up and running when the
configuration of the subscription takes effect on the monitored device.
The first message MUST be a separate subscription-started notification
to indicate the Receiver that the stream has started flowing. Then, the
notifications can be sent immediately without delay. All the
subscription state notifications, as defined in , MUST be encapsulated in separate notification
messages.In this section, we specify the UDP-Notif Transport behavior. describes the general design of the solution.
specifies the UDP-Notif message format.
describes a generic optional sub TLV
format. uses such options to provide
a segmentation solution for large UDP-Notif message payloads. describes the encoding of the message
payload.As specified in Sub-Notif, the telemetry data is encapsulated in
the NETCONF/RESTCONF notification message, which is then encapsulated
and carried using transport protocols such as TLS or HTTP2. illustrates the structure of an UDP-Notif
message.The Message Header contains information that facilitate the
message transmission before deserializing the notification
message.Notification Message is the encoded content that the
publication stream transports. The common encoding methods
include, CBOR, JSON, and XML. describes the
structure of the Notification Message for single notifications and
bundled notifications.The UDP-Notif Message Header contains information that facilitate
the message transmission before deserializing the notification
message. The data format is shown in .The Message Header contains the following field:Ver represents the PDU (Protocol Data Unit) encoding version.
The initial version value is 0.S represents the space of encoding type specified in the ET
field. When S is unset, ET represents the standard encoding types
as defined in this document. When S is set, ET represents a
private space to be freely used for nonstandard encodings.ET is a 4 bit identifier to indicate the encoding type used for
the Notification Message. 16 types of encoding can be expressed.
When the S bit is unset, the following values apply:0: CBOR;1: JSON;2: XML;others are reserved.Header Len is the length of the message header in octets,
including both the fixed header and the options.Message Length is the total length of the message within one
UDP datagram, measured in octets, including the message
header.Observation-Domain-ID is a 32-bit identifier of the Observation
Domain that led to the production of the notification message, as
defined in . This allows
disambiguation of an information source, such as the
identification of different line cards sending the notification
messages. The source IP address of the UDP datagrams SHOULD NOT be
interpreted as the identifier for the host that originated the
UDP-Notif message. Indeed, the streamer sending the UDP-Notif
message could be a relay for the actual source of data carried
within UDP-Notif messages.The Message ID is generated continuously by the sender of
UDP-Notif messages. Different subscribers share the same Message
ID sequence.Options is a variable-length field in the TLV format. When the
Header Length is larger than 12 octets, which is the length of the
fixed header, Options TLVs follow directly after the fixed message
header (i.e., Message ID). The details of the options are
described in the following section.All the options are defined with the following format, illustrated
in .Type: 1 octet describing the option type;Length: 1 octet representing the total number of octets in the
TLV, including the Type and Length fields;Variable-length data: 0 or more octets of TLV Value.The UDP payload length is limited to 65535. Application level
headers will make the actual payload shorter. Even though binary
encodings such as CBOR may not require more space than what is left,
more voluminous encodings such as JSON and XML may suffer from this
size limitation. Although IPv4 and IPv6 senders can fragment
outgoing packets exceeding their Maximum Transmission Unit(MTU),
fragmented IP packets may not be desired for operational and
performance reasons.Consequently, implementations of the mechanism SHOULD provide a
configurable max-segment-size option to control the maximum size of
a payload.The Segmentation Option is to be included when the message
content is segmented into multiple pieces. Different segments of one
message share the same Message ID. An illustration is provided in
. The fields of this TLV are:Type: Generic option field which indicates a Segmentation
Option. The Type value is to be assigned.Length: Generic option field which indicates the length of
this option. It is a fixed value of 4 octets for the
Segmentation Option.Segment Number: 15-bit value indicating the sequence number
of the current segment. The first segment of a segmented message
has a Segment Number value of 0.L: is a flag to indicate whether the current segment is the
last one of the message. When 0 is set, the current segment is
not the last one. When 1 is set, the current segment is the last
one, meaning that the total number of segments used to transport
this message is the value of the current Segment Number + 1.An implementation of this specification MUST NOT rely on IP
fragmentation by default to carry large messages. An implementation
of this specification MUST either restrict the size of individual
messages carried over this protocol, or support the segmentation
option.UDP-Notif message data can be encoded in CBOR, XML or JSON format.
It is conceivable that additional encodings may be supported in the
future. This can be accomplished by augmenting the subscription data
model with additional identity statements used to refer to requested
encodings.Implementation MAY support multiple encoding methods per
subscription. When bundled notifications are supported between the
publisher and the receiver, only subscribed notifications with the
same encoding can be bundled in a given message.In this section, we provide an applicability statement for the
proposed mechanism, following the recommendations of .The proposed mechanism falls in the category of UDP applications
"designed for use within the network of a single network operator or on
networks of an adjacent set of cooperating network operators, to be
deployed in controlled environments". Implementations of the proposed
mechanism should thus follow the recommendations in place for such
specific applications. In the following, we discuss recommendations on
congestion control, message size guidelines, reliability
considerations.The proposed application falls into the category of applications
performing transfer of large amounts of data. It is expected that the
operator using the solution configures QoS on its related flows. As
per , such applications MAY choose not to
implement any form of congestion control, but follow the following
principles.It is NOT RECOMMENDED to use the proposed mechanism over
congestion-sensitive network paths. The only environments where
UDP-Notif is expected to be used are managed networks. The deployments
require that the network path has been explicitly provisioned to
handle the traffic through traffic engineering mechanisms, such as
rate limiting or capacity reservations.Implementation of the proposal SHOULD NOT push unlimited amounts of
traffic by default, and SHOULD require the users to explicitly
configure such a mode of operation.Burst mitigation through packet pacing is RECOMMENDED. Disabling
burst mitigation SHOULD require the users to explicitly configure such
a mode of operation.Applications SHOULD monitor packet losses and provide means to the
user for retrieving information on such losses. The UDP-Notif Message
ID can be used to deduce congestion based on packet loss detection.
Hence the receiver can notify the device to use a lower streaming
rate. The interaction to control the streaming rate on the device is
out of the scope of this document. recommends not to rely on IP fragmentation
for messages whose size result in IP packets exceeding the MTU along
the path. The segmentation option of the current specification permits
segmentation of the UDP Notif message content without relying on IP
fragmentation. Implementation of the current specification SHOULD
allow for the configuration of the MTU.The target application for UDP-Notif is the collection of
data-plane information. The lack of reliability of the data streaming
mechanism is thus considered acceptable as the mechanism is to be used
in controlled environments, mitigating the risk of information loss,
while allowing for publication of very large amounts of data.
Moreover, in this context, sporadic events when incomplete data
collection is provided is not critical for the proper management of
the network, as information collected for the devices through the
means of the proposed mechanism is to be often refreshed.A receiver implementation for this protocol SHOULD deal with
potential loss of packets carrying a part of segmented payload, by
discarding packets that were received, but cannot be re-assembled as a
complete message within a given amount of time. This time SHOULD be
configurable.The YANG model defined in Section 9 has two leaf's augmented into one
place of Sub-Notif, plus one identity.This RFC requests that IANA assigns one UDP port number in the
"Registered Port Numbers" range with the service name "udp-notif". This
port will be the default port for the UDP-based notification Streaming
Telemetry (UDP-Notif) for NETCONF and RESTCONF. Below is the
registration template following the rules of .Service Name: udp-notifTransport Protocol(s): UDPAssignee: IESG <iesg@ietf.org>Contact: IETF Chair <chair@ietf.org>Description: UDP-based Publication Streaming TelemetryReference: RFC XXXXPort Number: PORT-XIANA is requested to assign a new URI from the IETF XML Registry. The following URI is
suggested:This document also requests a new YANG module name in the YANG Module Names registry with the following
suggestion:TBDThe authors of this documents would like to thank Alexander Clemm,
Eric Voit, Huiyang Yang, Kent Watsen, Mahesh Jethanandani, Stephane
Frenot, Timothy Carey, Tim Jenkins, and Yunan Gu for their constructive
suggestions for improving this document.Subscription to Distributed NotificationsHuaweiHuaweiCisco SystemsSwisscomINSA-Lyon