Protocol Assisted Protocol (PAP)
draft-li-rtgwg-protocol-assisted-protocol-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zhenbin Li , Lei Li, Yunan Gu | ||
| Last updated | 2019-07-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-rtgwg-protocol-assisted-protocol-00
Network Working Group Z. Li
Internet-Draft L. Li
Intended status: Standards Track Y. Gu
Expires: January 8, 2020 Huawei
July 7, 2019
Protocol Assisted Protocol (PAP)
draft-li-rtgwg-protocol-assisted-protocol-00
Abstract
For routing protocol troubleshooting, different approaches exibit
merits w.r.t. different situations. They can be generally divided
into two categories, the distributive way and the centralized way. A
very commonly used distributive approach is to log in possiblly all
related devices one by one to check massive data via CLI. Such
approach provides very detailed device information, however it
requires operators with high NOC (Network Operation Center)
experience and suffers from low troubleshooting efficiency and high
cost. The centralized approach is realized by collecting data from
devices via approaches, like the streaming Telemetry or BMP(BGP
Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to
analyze all gathered data. Such approach allows a comprehensive view
fo the whole network and facilitates automated troubleshooting, but
is limited by the data collection boundary set by different
management domains, as well as high network bandwidth and CPU
computation costs.
This document proposes a semi-distributive and semi-centralized
approach for fast routing protocol troubleshooting, localizing the
target device and possibly the root cause, more precisely. It
defines a new protocol, called the PAP (Protocol assisted Protocol),
for devices to exchange protocol related information between each
other in both active and on-demand manners. It allow devices to
request specific information from other devices and receive replies
to the requested data. It also allows actively transmission of
information without request to inform other devices to better react
w.r.t. network issues.
Requirements Language
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 [RFC2119].
Li, et al. Expires January 8, 2020 [Page 1]
Internet-Draft Protocol Assisted Protocol July 2019
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 January 8, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. PAP Usage Use cases . . . . . . . . . . . . . . . . . . . 5
1.2.1. Use Case 1: BGP Route Oscillation . . . . . . . . . . 5
1.2.2. Use Case 2: RSVP-TE Set Up Failure . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. PAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4. PAP Message Format . . . . . . . . . . . . . . . . . . . . . 8
4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Negotiation Message . . . . . . . . . . . . . . . . . . . 9
4.3. Request Message . . . . . . . . . . . . . . . . . . . . . 10
4.4. Reply Message . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Notification Message . . . . . . . . . . . . . . . . . . 11
4.6. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 12
Li, et al. Expires January 8, 2020 [Page 2]
Internet-Draft Protocol Assisted Protocol July 2019
5. PAP Operations . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Capability Negotiation Process . . . . . . . . . . . . . 12
5.2. Data Request and Reply Process . . . . . . . . . . . . . 14
5.3. Data Notification Process . . . . . . . . . . . . . . . . 14
6. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
A healthy control plane, providing network connectivity, is the
foundation of a well-functioning network. There have been rich
routing and signaling protocols designed and used for IP networks,
such as IGP (ISIS,OSPF), BGP, LDP, RSVP-TE and so on. The health
issues of these protocols, such as neighbor/peer disconnect/set up
failure, LSP set up failure, route flapping and so on, have been
devoted with ongoing efforts for diagnosing and remediation.
1.1. Motivation
The distributive protocol troubleshooting approach is typically
realized through manual per-device check. It's both time- and labor-
consuming, and requires NOC experience of the operators. Amongst
all, localizing the target device is usually the most diffcult and
time-consuming part. For example, in the case of route loop,
operators first log in a random deivce that reports TTL alarms, and
then check the looped route in the Forwarding Information Base (FIB)
and/or the Routing Information Base (RIB). It requires device by
device check, as well as manul data correlation, to pin point to the
exact responsible device, since the information retrival and analysis
of such distributive way is fragmented. In addition, the low
efficiency and manul troubleshooting activities may further impact
new network services and/or enlarge affected areas.
The centralized network OAM, by collecting network-wide data from
devices, enables automatic routing protocol troubleshooting. Date
collection protocols, such as SNMP (Simple Network Management
Protocol) [RFC1157], NETCONF (Network Configuration Protocol)
[RFC6241], and (BMP) [RFC7854], can provide various information
retrival, such as network states, routing data, configurations and so
on. Such centrazlized way relies on the existence of a centralized
server/controller, which is not supported by some legacy networks.
What's more, even with the existence of a centralized server/
controller, it can only collect the data within its own management
domain, while the cross-domain data are not available due to
independent managment of different ISPs. Thus, the lack of such
Li, et al. Expires January 8, 2020 [Page 3]
Internet-Draft Protocol Assisted Protocol July 2019
information may lead to troubleshooting failure. In addition,
centralized approaches may suffer from high network bandwidth and CPU
computation consumptions.
Another way of protocol troubleshooting is utilzing the protocol
itself to convey diagnosing information. For example, some reason
codes are carried in the Path-Err/ResvErr messages of RSVP-TE, so
that to other nodes may know the why the tunnel fails to be set up.
Such approaches is semi-distributive and semi-centralized. It does
not rely on the deployment of a centralized server, but still gets
partial global view of the network. However, there still requires
non-trivial augementation works to existing routing protocols in
order to support troubleshooting. This then raises the question that
whether such non-routing data is suitable to be carried in these
routing protocols. The extra encapsulation, parsing and analyzing
work for the non-routing data would further slow down the network
convergence. Thus, it's better to separate the routing and non-
routing data transmission as well as data parsing. In addition,
coexisting with legacy devices may cause interop issues. Thus,
relying on augumenting existing routing protocols without network-
wide upgrading may not only fail to provide the truobleshooting
benefit, but further affect the operation of the existing routing
system. What's more, the failure of routing protocol instance would
lead to the failure of diagnosing itself. All in all, it's
reasonable to separate the protocol diagnosing data
generation/encapsulation/transmission/parsing from the protocol
itself.
This document proposes a new protocol, called the PAP (Protocol
assisted Protocol), for devices to exchange protocol related
information between each other. It allows both active and on-demand
data exchange. Considering that massiveness of protocol/routing
related data, the intuitive of designing PAP is not to exchange the
comprehensive protocol/routing status between devices, but to provide
very specific information required for the contemprary
troubleshooting. The benefits of such a semi-distributive and semi-
centralized approach are summarized as follows:
1. It facilitates automatic troubleshooting without requiring manul
device by device check.
2. It allows individual device to have a more global view by
requesting data from other devices.
3. It does not rely on the deployement of a centralized server/
controller.
Li, et al. Expires January 8, 2020 [Page 4]
Internet-Draft Protocol Assisted Protocol July 2019
4. It passes the dtata collection boundary set by different
management domains by cross-domain data exchange between devices.
5. It relieves the bandwidth pressure of network-wide data
collection, and the processing pressure of the centralized
server.
6. It does not affect the running of existing routing protocols.
1.2. PAP Usage Use cases
PAP allows both data request/reply and data notitication between
devices. PAP speakers use the exchanged PAP data to help fast
localize the network issues.
1.2.1. Use Case 1: BGP Route Oscillation
A BGP route oscillation can be caused by various reasons, and usually
leaves network-wide impact. In order to find the root cause and take
remediation actions, the first step is to localize the oscillation
source. In this case, a BGP speaker can send a PAP Request Message
to the next hop device of the oscillating route asking " Are you the
oscillation source?". If the BGP speaker is the oscillation source,
possiblly knows by running a device diagnosing system, replies with a
PAP Reply Message saying that "I'm the oscillation source!" to the
device who sends the PAP Request Message. If the BGP speaker is not
the oscillation source, it further asks the same question with a PAP
Request Message to its next hop device of the oscillating route.
This request and reply process continues util the request has reached
the oscillation source. The source device then sends a PAP Reply
Message to tell its upstream device along the PAP request path that "
I am the oscillation source!", and then "xx is the oscillation
source!" information is further sent back hop by hop to the device
who originates the request.
1.2.2. Use Case 2: RSVP-TE Set Up Failure
The MPLS label switch path set up, either using RSVP-TE or LDP, may
fail due to various reasons. Typical troubleshooting procedures are
to log in the device, and then check if the failure lies on the
configuration, or path computation error, or link failure.
Sometimes, it requires the check of multiple devices along the
tunnel. Certain reason codes can be carried in the Path-Err/ResvErr
messages of RSVP-TE, while other data are currently not supported to
be transmitted to the path ingress/egress node, such as the
authentication failure. Using PAP, the device, which is reponsible
for the tunnel set up failure, can send the PAP Notification Message
to the Ingress device, and possibly with some reason codes so that
Li, et al. Expires January 8, 2020 [Page 5]
Internet-Draft Protocol Assisted Protocol July 2019
the ingress device can not only localize the target device but also
the root cause.
2. Terminology
IGP: Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System
OSPF: Open Shortest Path First
BGP: Boarder Gateway Protocol
BGP-LS: Boarder Gateway Protocol-Link State
MPLS: Multi-Protocol Label Switching
RSVP-TE: Resource Reservation Protocol-Traffic Engineering
LDP: Label Distribution Protocol
BMP: BGP Monitoring Protocol
LSP: Link State Packet
IPFIX: Internet Protocol Flow Information Export
PAP: Protocol assisted Protocol
UDP: User Datagram Protocol
3. PAP Overview
PAP is a non-routing protocol used for PAP speakers to exchange
routing protocol related information. The primary function of PAP is
to provide a unfied tunnel for protocol diagnosing information
exchange without augumenting each specific protocol.
PAP uses UDP as its transport protocol, which is connectionless. The
reason that UDP is selected over TCP is because PAP is intended for
on-demand communications. The PAP packet is defined as follows.
This document requires the assignment of a User Port registry for the
UDP Destination Port.
Li, et al. Expires January 8, 2020 [Page 6]
Internet-Draft Protocol Assisted Protocol July 2019
+-------------+-------------+-------------+-------------+-------------+
| ETH. Header | IP Header | UDP Header | PAP Header | PAP Payload |
+-------------+-------------+-------------+-------------+-------------+
Figure 1. Encapsulation in UDP
This document uses PAP speakers to refer to two routing devices that
support PAP and/or communicate with each other using PAP throughout.
The communications between two PAP speakders should follow three
major processes, i.e., the Capability Negotiation Process, the
Request and Reply Process, and the Notification Process. This
document defines 5 PAP Message types, i.e., Negotiation Message,
Request Message, Reply Message, Notification Message, and ACK
Message, which are used in the above PAP processes.
Although PAP is connectionless, there still requires a successful
Caoability Negotiation between two PAP speakers before the exchange
of any PAP messages (except the Negotiation Message). The purpose of
the Capability Negotiation process is to inform both PAP speakders of
each other's PAP capabilties. The capabilities of a PAP speaker
refer to the support of diagnosing information exchange of specific
protocols, while the generation of such data are possibly enabled by
a local protocol diagnosing system. The negotiation can be initiated
by either the local or remote PAP speaker through sending out a PAP
Negotiation Message. The Negotiation Message may or may not require
an ACK Message, as indicated in the Negotiation Message. A
successful negotiation is achieved if both PAP speakers have
correctly received the other speakder's Negotiation Message
regardless of the message content. A more detailed definition of a
successful negotiation is defined in Section 5.1. After a successful
negotiation, two PAP speakers can exchange any PAP Message on-demand.
The purpose of the Request and Reply process is to acquire
information needed by a PAP speaker from other PAP speakers for
diagnosing a specific protocol. The Request and Reply Messages can
be customized for different protocols. The process starts by any PAP
speaker sending a Request Message to another PAP speaker. The PAP
receiver, after receiving the Request message, sends out a Reply
Message to the request sender. The generation of both Request and
Reply Messages is protocol-specific, and depends on possibaly a local
protocol diagnosing system. One Request Message received may further
results in a new Request Message generated and sent out to a third
PAP speaker, if the receiver does not have the answer to the sender.
Both Request and Reply Messages may or may not require an ACK
Message, as indicated in the Request/Reply Messages.
The Notification Process is used to serve active data notification.
Any PAP speaker, having information to share with other PAP speakers,
Li, et al. Expires January 8, 2020 [Page 7]
Internet-Draft Protocol Assisted Protocol July 2019
may start to send Notification Messages to any target PAP speaker.
This information sharing is also protocol-specific, and can be
possibly generated by a local protocl diagnosing system. The
Notification Message may or may not require an ACK Message, as
indicated in the Notification Message.
4. PAP Message Format
4.1. Common Header
The common header is encapsulated in all PAP messages. It includes
the following fields.
0 15 31
+----------------------+---------------------+
| Sequence Number | Length |
+-----------+----------+---------------------+
| Msg. Type |
+-----------+
Figure 2. PAP Common Header
o Sequence Number (2 byte): It is used to indicate the sequence of
the PAP Message. It uses unsigned integers to distinguish the PAP
Messages sent to the same remote device. The integer is set
incrementally in order time.
o Length (2 bytes): Length of the message in bytes, including the
Common Header and the following Message.
o Message Type (1 byte): This indicates the PAP message type.The
following types are defined, and listed as follows.
* Type = TBD1: Negotiation Message. It is used for two devices
to inform each other of the capabilties they support and no
longer support.
* Type = TBD2: Request Message.
* Type = TBD3: Reply Message.
* Type = TBD4: Notification Message.
* Type = TBD5: ACK Message. It is used to confirm to the local
device that the remote device has received a previous sent PAP
message, which can be either a Negotiation Message, a Request
Message, a Reply Message or an Notification Message.
Li, et al. Expires January 8, 2020 [Page 8]
Internet-Draft Protocol Assisted Protocol July 2019
4.2. Negotiation Message
The Negotiation Message is used for both capabilty negotiation
between the local PAP speaker and the remote PAP speaker. It is also
used to indicate the enabling and distabling of any supported
capabiliity. The Negotiation Message is required to be exchanged
before two PAP speaers can exchange any other PAP Message types.
0 15 31
+--------------------------------------------+
| Version |A|C| Reserved |
+--------------------------------------------+
| Protocol Capability |
+--------------------------------------------+
| Optional Capability |
+--------------------------------------------+
Figure 3. PAP Negotiation Message
o Version (2 bytes): It indicates the PAP version. The current
version is 0.
o Flags (2 bytes): Two flag bits are currently defined.
* The A bit is used to indicate if an ACK Message from the remote
PAP speaker is required for each Negotiation Message sent. If
an ACK is required, then the A bit SHOULD be set to "1", and
"0" otherwise.
* The C bit is used to indicate the enabling/disabling of the
capabilities that carried in the Protocol Capability field. If
the local device wants to inform the remote device of enabling
one or more capabilities, the C bit SHOULD be set to "1". If
the local device wants to inform the remote device of disabling
one or more capabilities, the C bit SHOULD be set to "0".
o Protocol Capability (4 bytes): It is 4-byte bit map that indicates
the capability of inforamtion exchange regarding various
protocols. Each bit represents one protocol. For example, the
right most bit of the Protocl Capability represents the capability
of exchanging IS-IS protocol related information. The format and
definition of information exchanged, regarding each protocol, MUST
follow the PAP Message format and definition.
o Optional Capability (4 bytes): It is 4-byte bit map that indicates
the capability of other inforamtion. It can be used to carry
other application-specific information, which allows future
extension. Its format and definition remains to be determined.
Li, et al. Expires January 8, 2020 [Page 9]
Internet-Draft Protocol Assisted Protocol July 2019
4.3. Request Message
The Request Message is used for the local device to request specific
data regarding one specific protocol or application from the remote
device. It MUST be sent after a successful Capability Negotiation
Process (described in Section 5.1), and the requested protocol/
application MUST be supported by both the local and remote devices,
as indicated in the Negotiation Messages exchanged between the local
and remote devices.
The Statistic TLV is defined as follows.
0 15 31
+----------------------+
|A| Reserved |
+----------------------+---------------------+
| Capability |
+--------------------------------------------+
| Data Request |
+--------------------------------------------+
Figure 4. PAP Request Message
o Flags (2 bytes): The A bit is used to indicate if an ACK Message
from the remote PAP speaker is required for each Request Message
sent. If an ACK is required, then the A bit SHOULD be set to "1",
and "0" otherwise.
o Capability (4 bytes): It is 4-byte bit map that indicates the
specific protocol/application the Request Message is requesting
data for. The respective bit of this specific protocol/
application MUST be set to "1", and the rest of the bits MUST be
set to "0".
o Data Request (Variable): Specifies what data the local device is
requesting. The specific format remains to be determined.
4.4. Reply Message
The Reply Message is used to carry the information that the local
device requests from the remote device through the Request Message.
Li, et al. Expires January 8, 2020 [Page 10]
Internet-Draft Protocol Assisted Protocol July 2019
0 15 31
+----------------------+
|A| Reserved |
+----------------------+---------------------+
| Capability |
+--------------------------------------------+
| Data Reply |
+--------------------------------------------+
Figure 5. PAP Request Message
o Flags (2 bytes): The A bit is used to indicate if an ACK Message
from the remote PAP speaker is required for each Request Message
sent. If an ACK is required, then the A bit SHOULD be set to "1",
and "0" otherwise.
o Capability (4 bytes): It is 4-byte bit map that indicates the
specific protocol/application the Reply Message is replying for.
The respective bit of this specific protocol/application MUST be
set to "1", and the rest of the bits MUST be set to "0".
o Data Reply (Variable): It contains the data that the local device
requests from the remote device. The specific format remains to
be determined.
4.5. Notification Message
The Notification Message is used to carry the information that the
local device sends to the remote device.
0 15 31
+----------------------+
|A| Reserved |
+----------------------+---------------------+
| Capability |
+--------------------------------------------+
| Data Nitification |
+--------------------------------------------+
Figure 6. PAP Notification Message
o Flags (2 bytes): The A bit is used to indicate if an ACK Message
from the remote PAP speaker is required for each Request Message
sent. If an ACK is required, then the A bit SHOULD be set to "1",
and "0" otherwise.
o Capability (4 bytes): It is 4-byte bit map that indicates the
specific protocol/application the Notification Message is
Li, et al. Expires January 8, 2020 [Page 11]
Internet-Draft Protocol Assisted Protocol July 2019
notifying for. The respective bit of this specific protocol/
application MUST be set to "1", and the rest of the bits MUST be
set to "0".
o Data Notification (Variable): It contains the data that the local
device actively sends to the remote device. The specific format
remains to be determined.
4.6. ACK Message
The ACK Message is used to confirm that the remote device has
received a PAP Message that set the A bit to "1". The ACK Message
includes only the ACK sequence Number field, which MUST be set to the
sequence number carried in the PAP Common Header of the received PAP
message, which requires this ACK Message.
0 15 31
+--------------------------------------------+
| ACK Sequence Number |
+--------------------------------------------+
Figure 7. PAP ACK Message
5. PAP Operations
The PAP operations include the following 3 processes, the Capability
Negotiation Process, the Data Request and Reply Process, and the Data
Notification Process.
5.1. Capability Negotiation Process
The Capability Negotiation process refers to the process that two
devices inform each other of the capabilties they support and no
longer support. A successful negotiation that inform each other of
the supported capabilities between two devices MUST be achieved
before the exchange of any other PAP Message.
The first Negotiation Message can be sent at any time per the local
device's configuration. One or more Negotiation Messages can be sent
at any time after the first Negotiation Message. Once a Negotiation
Message is sent from a local device, an ACK Message from the remote
device is required/or not per the indication of the "A" bit in the
Negotiation Message. If the A bit is set to "1" (i.e., ACK is
required), the local device SHUOLD wait for the ACK Message from the
remote device for a certain time period before taking further
actions, and if no ACK Message is received within this time frame,
the local device SHOULD resend the Negotiation Message to the remote
device. The waiting period can be configured locally. This send and
Li, et al. Expires January 8, 2020 [Page 12]
Internet-Draft Protocol Assisted Protocol July 2019
wait process CAN be repeated for at most 3 times before receiving a
ACK Message from the remote device. If after 3 times of resending
the Negotiation Message, still no ACK received, then this negotiation
is treated as unsuccessful. If the A bit is set to "0", then the
local device does not wait for any ACK Message. If no Negotiation
Message is received from the remote device within a time frame, the
local device can resend the Negotiation Message. This send and wait
process CAN be repeated for at most 3 times before receiving a
Negotiation Message from the remote device. If after 3 times of
resending the Negotiation Message, still no Negotiation Message
received, then this negotiation is treated as Unsuccessful. The
waiting period can be configured locally. Once a Negotiation Message
is received from the remote device, the negotiation between the two
devices is treated as successful regardless from the local device's
perspective.
On the other hand, the remote device, after receiving the Negotiation
Message from the local device, SHOULD send out its own Negotiation
Message that indicates the capabilities that it supports. If the A
bit of the received Negotiation Message from the local device is set
to "1", the remote device SHOULD sent an ACK Message before sending
the new Negotiation Message. After the remote device sends out the
Negotiation Message back to the local device, it waits/or not for the
ACK message, depending on if the A bit of the Negotiation Message
sent to the local device is set to "1". If it's set to "1", the
remote device waits for the ACK message for a certain time period
before taking further actions. If no ACK Message is received within
this time frame, the remote device SHOULD resend the Negotiation
Message to the local device. The waiting period can be configured
locally at the remote device. This send and wait process CAN be
repeated for at most 3 times before receiving a ACK Message from the
local device. If after 3 times of resending the Negotiation Message,
still no ACK received, then the remote device treats this negotiation
as unsuccessful, and successful otherwise. If the A bit of the
Negotiation Message sent from the remote device is set to "0", then
the remote device treats the negotiation as successful after sending
out the Negotiation Message.
The C bit in the Negotiation Message MUST always be set to "1" before
the negotiation is successful. A successful Capability Negotiation
means that both the local and remote devices have the information of
what capabilties the other side support so that when exchanging any
other messages, only the capabilities that are supported by both ends
SHOULD be carried in the respective capabilty fields.
Another process of the Capability Negotiation Process is to inform
the remote device of the capability/capabilities that the local
device no longer supports with the indication of C bit set as "0".
Li, et al. Expires January 8, 2020 [Page 13]
Internet-Draft Protocol Assisted Protocol July 2019
To inform the other device of the disabled capabiliity/capabilities,
the local device MUST have sent one or more Negotiation Messages that
indicate the support of such capability/capabilities previously.
5.2. Data Request and Reply Process
After a successful Capability Negotiation, the local device CAN send
the Data Request Message to the remote device per local
configuration. An Reply Message SHOULD only be sent after receiving
a Request Message. If the A bit of the Request Message is set to "1"
(i.e., ACK is required), the local device SHUOLD wait for the ACK
Message from the remote device for a certain time period before
taking further actions, and if no ACK Message is received within this
time frame, the local device SHOULD resend the Request Message to the
remote device. The waiting period can be configured locally. This
send and wait process CAN be repeated for at most 3 times before
receiving a ACK Message from the remote device. If the A bit is set
to "0", then the local device does not wait for any ACK Message. If
no Reply Message is received from the remote device within a time
frame, the local device can resend the Request Message. This send
and wait process CAN be repeated for at most 3 times before receiving
a Reply Message from the remote device. If after 3 times of
resending the Request Message, still no Reply Message received, then
no further action is taken. The waiting period can be configured
locally.
On the other hand, the remote device, after receiving the Request
Message from the local device, SHOULD send out the Reply Message to
reply the requst. If the A bit of the received Request Message from
the local device is set to "1", the remote device SHOULD sent an ACK
Message before sending the Reply Message.
To request data for multiple protocols/applications, seperate Request
Messages SHOULD be sent, with each Request Message requesting one
specific protocol/application data. According, the Reply Message is
also sent sperately per each Request Message.
5.3. Data Notification Process
The Notification Message CAN be sent by the local or the remote
device at any time once the Capability Negotiation is successful.
Each Notification Message SHOULD only indicate one specific protocol/
application. The A bit can be set to "1" or "0" to allow the local/
remote device to know if the other device has received the
Notification Message through the ACK Message.
Li, et al. Expires January 8, 2020 [Page 14]
Internet-Draft Protocol Assisted Protocol July 2019
6. IANA
TBD
7. Contributors
TBD
8. Acknowledgments
TBD
9. References
[I-D.brockners-inband-oam-requirements]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
T., Lapukhov, P., and r. remy@barefootnetworks.com,
"Requirements for In-situ OAM", draft-brockners-inband-
oam-requirements-03 (work in progress), March 2017.
[I-D.ietf-netconf-yang-push]
Clemm, A. and E. Voit, "Subscription to YANG Datastores",
draft-ietf-netconf-yang-push-25 (work in progress), May
2019.
[I-D.song-ntf]
Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z.,
Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a
Network Telemetry Framework", draft-song-ntf-02 (work in
progress), July 2018.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
Li, et al. Expires January 8, 2020 [Page 15]
Internet-Draft Protocol Assisted Protocol July 2019
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
<https://www.rfc-editor.org/info/rfc1213>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
Signalling Extensions for the Label Distribution
Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
<https://www.rfc-editor.org/info/rfc3988>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
Authors' Addresses
Zhenbin Li
Huawei
156 Beiqing Rd
Beijing
China
Email: lizhenbin@huawei.com
Li, et al. Expires January 8, 2020 [Page 16]
Internet-Draft Protocol Assisted Protocol July 2019
Lei Li
Huawei
156 Beiqing Rd
Beijing
China
Email: lily.lilei@huawei.com
Yunan Gu
Huawei
156 Beiqing Rd
Beijing
China
Email: guyunan@huawei.com
Li, et al. Expires January 8, 2020 [Page 17]