Internet DRAFT - draft-lan-nvo3-qtp
draft-lan-nvo3-qtp
INTERNET-DRAFT J. Lan
Intended Status: Proposed Standard D. Cheng
Expires: April 2, 2024 Y. Hu
G. Cheng
T. Duan
National Digital Switching System Engineering and Technological
Research Center, P.R.China
October 2, 2023
QoS-level aware Transmission Protocol (QTP) for virtual networks
draft-lan-nvo3-qtp-18
Abstract
This document provides a QoS-level aware Transmission Protocol (QTP)
for virtual networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lan, et al. Expires April 2, 2024 [Page 1]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Motivation and background . . . . . . . . . . . . . . . . . 4
1.2 QTP-path . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 QTP Overview . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5
2 QTP Data Encapsulation Specification . . . . . . . . . . . . . 5
2.1 QTP Header Specification . . . . . . . . . . . . . . . . . 5
2.2 QTP Data Encapsulation . . . . . . . . . . . . . . . . . . 6
3 QTP Message Specification . . . . . . . . . . . . . . . . . . . 7
3.1 Destination Prefix and Node Identifiers . . . . . . . . . . 8
3.1.1 Destination Prefix (DestPrefix) . . . . . . . . . . . . 8
3.1.2 Node Identifiers . . . . . . . . . . . . . . . . . . . . 8
3.2 QTP PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 TLV Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 DestPrefix TLV . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 PID TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3 ToP TLV . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4 Status TLV . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 QTP messages . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Notification Message . . . . . . . . . . . . . . . . . . 16
3.4.1.1 Notification Message Procedures . . . . . . . . . . 17
3.4.1.2 Events Signaled by Notification Messages . . . . . . 17
3.4.2 KeepAlive Message . . . . . . . . . . . . . . . . . . . 19
3.4.2.1 KeepAlive Message Procedures . . . . . . . . . . . . 19
3.4.3 PID Request Message . . . . . . . . . . . . . . . . . . 19
3.4.3.1 PID Request Message Procedures . . . . . . . . . . . 20
3.4.4 PID Response Message . . . . . . . . . . . . . . . . . . 21
3.4.4.1 PID Response Message Procedures . . . . . . . . . . 22
3.4.5 PID Release Message . . . . . . . . . . . . . . . . . . 22
3.4.5.1 PID Release Message Procedures . . . . . . . . . . . 23
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1 Message Summary . . . . . . . . . . . . . . . . . . . . 24
3.5.2 TLV Summary . . . . . . . . . . . . . . . . . . . . . . 24
Lan, et al. Expires April 2, 2024 [Page 2]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
3.5.3 Status Code Summary . . . . . . . . . . . . . . . . . . 24
4 QTP Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Establishment of QTP-Path . . . . . . . . . . . . . . . . . 25
4.1.1 The trigger condition of QTP-Path establishing . . . . . 25
4.1.2 Path establishment process . . . . . . . . . . . . . . . 25
4.2. Removal of the QTP-Path . . . . . . . . . . . . . . . . . . 27
4.2.1 The trigger condition of removal process . . . . . . . . 27
4.2.2 QTP-Path removal process . . . . . . . . . . . . . . . . 27
4.3. QTP-Path adjustment process . . . . . . . . . . . . . . . . 27
4.3.1 The trigger condition of QTP-Path adjustment . . . . . . 27
4.3.2 QTP-Path Adjustment Process . . . . . . . . . . . . . . 28
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 28
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1 Normative References . . . . . . . . . . . . . . . . . . . 28
7.2 Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Lan, et al. Expires April 2, 2024 [Page 3]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
1 Introduction
1.1 Motivation and background
Virtual network has been designed to implement all types of network,
to achieve scalability in today's Internet, for example, multi-
tenants sharing network in data center network. This document
provides a QoS-level aware Transmission Protocol (QTP) for virtual
networks. Since virtual network transmits data in the form of "best
effort" under today's connectionless network, its performance cannot
be guaranteed. In addition, due to the elasticity of network traffic,
virtual networks sharing the same physical network cannot achieve
minimum resource guarantee and fairness under network congestion. QTP
constructs various data transmission tunnels, namely, QTP-path, for
different virtual networks that have special requests. We embed a
field named QTP-path identifier (PID) in QTP header, and explicitly
contains QoS level to indicate the resource level sharing when data
transmission.
1.2 QTP-path
The applications on the virtual network always originate requirements
that have identical path and performance. Therefore, QTP aggregates
these requirements, and constructs one data transmission tunnel to
maximize network throughput. The tunnel, we say, QTP-path is labeled
by a QoS level according with the requests in the protocol header.
1.3 QTP Overview
We assume that all the network nodes can handle global knowledge
about network loads and application requests. If there are several
pairs in network originate requests for identical QoS level and have
common in path, then the management plane decides to establish a QTP-
path in the common part of the path. Firstly, the starting node
assign a PID to the path, and send QTP-path establish request. Then
the relative nodes on the path update their path information base
(PIB) which storage the PIDs of QTP-paths across it. Finally, when
the QTP-path has been established, the data transmitted over it can
be transfer based on PIB matching PID in PDUs, and realize QoS level
guarantee.
1.4 Terminology
QTP-path the tunnel established for the same requests by
QTP can be used to transmission data.
QTP-path identifier represented as a 32-bit number in a 4 octet field
Node Identifier a four octet quantity used to identify an
QTP Node.
Lan, et al. Expires April 2, 2024 [Page 4]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
1.5 Acronyms and Abbreviations
PDU protocol data unit
TTL Time to live
ToP Type of QTP-path
PID QTP-path Identifier
TTL Time to live
TLV Type-Length-Value
PIB QTP-path information base
2 QTP Data Encapsulation Specification
2.1 QTP Header Specification
Each packet over QTP-path MUST have a QTP header. The QTP header is
represented by 4 octets. This is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP | PID | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP: Type of QTP-path, 6 bits
PID: QTP-path Identifier, 18 bits
TTL: Time to live, 8 bits
Figure 1
The QTP header appears AFTER the data link layer header, but BEFORE
any network layer header. Each QTP header is broken down into the
following fields:
o Type of QTP-path (ToP)
This six-bit field is used to identify the type of QTP-path.
Each type of QTP-path SHALL carry only one class of traffic. RFC
4594 has defined twelve different classes of traffic, namely,
network control, telephony, signaling, multimedia conferencing,
real-time interactive, multimedia streaming, broadcast video,
low-latency data, OAM, high-throughput data, standard, and low-
priority data. End-to-end quantitative performance requirements
may be obtained from ITU-T Recommendations Y.1541 and Y.1540. It
is RECOMMENDED that the value of ToP be the same with DSCP
value.
o QTP-path Identifier (PID)
This 18-bit field carries the actual value of the QTP-Path
Lan, et al. Expires April 2, 2024 [Page 5]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
identifier. When a QTP-path packet is received, the PID value is
looked up to obtain the next hop to which the packet is to be
forwarded. Before forwarding, the PID may be replaced with
another, or be popped off with the whole QTP-path header.
o Time to live (TTL)
This eight-bit field is used to encode a time-to-live value. The
processing of this field is the same with that of MPLS TTL field
in RFC 3032.
Different types of QTP-paths MUST have different behaviors on QoS
guarantee and resource allocation to achieve their required traffic
characteristics.
2.2 QTP Data Encapsulation
The packet format for QTP-path is shown in Figure 2.
QTP header encapsulation is used to realize a QTP-path, and the
header by definition in section 2.1 contains a ToP, a PID, and a TTL.
NVGRE encapsulation is used to realize an overlay virtual network.
The virtual network identifier is carried as the 24-bit VSID in the
NVGRE header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x01FF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer QTP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP | PID | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lan, et al. Expires April 2, 2024 [Page 6]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
| Time to Live | Protocol=0x2F | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NVGRE Encapsulation:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NVGRE Encapsulation |
| (include NVGRE Header, Original Inner Ethernet Frame) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The QTP data encapsulation includes the outer Ethernet header, the
QTP-path header, the outer IPv4 header, and the NVGRE encapsulation:
o Outer Ethernet header: The source MAC address in the outer frame
is set to the MAC address associated with the NVGRE endpoint. The
destination MAC address is set to the MAC address of the nexthop
IP address for the destination NVE. The EtherType field is set to
0x01FF which is reserved for experimental use.
o QTP header: The ToP is used to identify the type of QTP-path,
the PID is used to identify the QTP-path, and the TTL is used to
record the time to live for the QTP-path.
o Outer IPv4 header: IPv4 is used as the delivery protocol for
NVGRE. The protocol field in the IPv4 header is set to 0x2F. The
IP address in the outer frame is referred to as the Provider
Address (PA).
o NVGRE encapsulation: It includes NVGRE header, and original
inner Ethernet frame. The VSID in NVGRE header can be used to
identify the different virtual networks. The original inner
Ethernet frame comprises of an inner Ethernet header followed by
the inner IP header, followed by the IP payload.
3 QTP Message Specification
QTP message exchanges are accomplished by sending QTP protocol data
units (PDUs) over TCP connections. Each QTP PDU can carry one or more
Lan, et al. Expires April 2, 2024 [Page 7]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
QTP messages. Note that the messages in a QTP PDU need not be related
to one another. For example, a single PDU could carry a PID Request
message, another message for PID Responding message, and a third
Notification message that signals some event.
3.1 Destination Prefix and Node Identifiers
3.1.1 Destination Prefix (DestPrefix)
A DestPrefix specification for each QTP-Path is provided to precisely
specify which packets may be mapped to each QTP-Path. The DestPrefix
identifies the set of IP packets that may be mapped to that QTP-Path.
This specification defines DestPrefix as an address prefix of any
length from 0 to a full address, inclusive. We give the rules used
for mapping packets to QTP-Path that have been set up using a
DestPrefix in the remainder of this section.
We say that a particular address matches a particular address prefix
if and only if that address begins with that prefix. We also say that
a particular packet matches a particular QTP-Path if and only if the
packet's destination address matches the DestPrefix of that QTP-Path.
The following rules describe the procedure for mapping a particular
packet to a particular QTP-Path.
- If a packet matches exactly one QTP-Path, the packet is mapped
to that QTP-Path.
- If a packet matches multiple QTP-Paths, it is mapped to the
QTP-Path whose matching DestPrefix is the longest.
- If it is known that a packet must traverse a particular egress
router, and there is a QTP-Path with a DestPrefix that is a /32
address of that router, then the packet is mapped to that QTP-
Path.
3.1.2 Node Identifiers
A Node Identifier is a four octet quantity used to identify a QTP
Node. The Node Identifier must be a globally unique value, such as a
32-bit router Id assigned to the QTP Node.
3.2 QTP PDU
Each QTP PDU consists of a QTP header and one or more QTP messages.
The QTP header is:
Lan, et al. Expires April 2, 2024 [Page 8]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
Two octet unsigned integer containing the version number of the
protocol. This version of the specification specifies QTP
protocol version 1.
PDU Length
Two octet integer specifying the total length of this PDU in
octets, excluding the Version and PDU Length fields.
Node Identifier
Four octet field that uniquely identifies the node and MUST be a
globally unique value. It SHOULD be a 32-bit router Id assigned to
the Node .
3.3 TLV Encoding
QTP uses a Type-Length-Value (TLV) encoding scheme to encode the
information carried in QTP messages.
A QTP TLV is encoded as a 2 octet field that uses 15 bits to specify
a Type and 1 bits to specify behavior when a Node doesn't recognize
the Type, followed by a 2 octet Length field, followed by a variable
length Value field.
Lan, et al. Expires April 2, 2024 [Page 9]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit
Unknown TLV bit. When an unknown TLV is recieved, if U is
clear(=0), a notification MUST be returned to the message
originator and the entire message MUST be ignored; if U is set
(=1), the unknown TLV MUST be silently ignored and the rest of the
message processed as if the unknown TLV did not exist.
Type
Encodes how the Value field is to be interpreted.
Length
Specifies the length of the Value field in octets.
Value
Octet string of Length octets that encodes information to be
interpreted as specified by the Type field.
Note that there is no alignment requirement for the first octet of a
TLV. TLVs may be nested, that is the Value field itself may contain
TLV encodings.
The TLV encoding scheme is very general. In principle, everything in
a QTP PDU could be encoded as a TLV. Note that the TLV scheme is not
used to its full generality in this specification.
The specification assigns type values for related TLVs, such as the
PID TLVs, from a contiguous block in the 16-bit TLV type number
space. Section "TLV Summary" lists the TLVs defined in this version
of the protocol.
In this section, the TLV encodings for some commonly used parameters
are specified.
Lan, et al. Expires April 2, 2024 [Page 10]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
3.3.1 DestPrefix TLV
PIDs are bound to DestPrefixes. A DestPrefix TLV encodes a list of
one or more DestPrefix Items.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| DestPrefix (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestPrefix Item 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestPrefix Item n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DestPrefix Item 1 to DestPrefix Item n
The DestPrefix Item encoding depends on the type of DestPrefix.
A DestPrefix value is encoded as a 1 octet field that specifies
the element type, and a variable length field that is the type-
dependent DestPrefix value.
The DestPrefix value encoding is:
DestPrefix Type Value type name
Wildcard 0x01 No value; i.e., 0 value octets;
See below.
Prefix 0x02 See below.
Wildcard DestPrefix
To be used only in the PID Release messages indicating that the
release is to be applied to all DestPrefixes associated with
the PID within the following PID TLV. Must be the only
DestPrefix Item in the DestPrefix TLV.
DestPrefix value encoding:
Lan, et al. Expires April 2, 2024 [Page 11]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
Two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [ASSIGNED_AF] that encodes the address family for
the address prefix in the Prefix field.
PreLen
One octet unsigned integer containing the length in bits of the
address prefix that follows. A length of zero indicates a
prefix that matches all addresses (the default destination), in
this case, the Prefix itself is zero octets.
Prefix
An address prefix encoded according to the Address Family
field, whose length was specified in bits in the PreLen field,
padded to a byte boundary.
When decoding a DestPrefix TLV, if a Node encounters a DestPrefix
with an Address Family it does not support, it SHOULD stop decoding
the DestPrefix TLV, abort processing the message containing the TLV,
and send an "Unsupported Address Family" Notification message to its
QTP peer. If a Node encounters a DestPrefix type it cannot decode, it
SHOULD stop decoding the DestPrefix TLV, abort processing the message
containing the TLV, and send an "Unknown DestPrefix " Notification
message to its QTP peer.
3.3.2 PID TLV
A PID TLV are used to encode a PID. The encoding for PID TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PID (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PID
This is a 18-bit PID value represented as a 18-bit number in a 4
octet field as follows:
Lan, et al. Expires April 2, 2024 [Page 12]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.3 ToP TLV
When establishing a QTP-Path, a ToP TLV is used to specify type of
QTP-Path and the QoS guarantee feature of the QTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ToP (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP
This is a 6-bit ToP value represented as a 6-bit number in a 4
octet field as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A ToP TLV with Length 0 is a WildCard ToP.
3.3.4 Status TLV
Status TLVs are carried in Notification messages to specify events
being signaled. The encoding for the Status TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Status (0x0400) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lan, et al. Expires April 2, 2024 [Page 13]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
U-bit
SHOULD be 0 when the Status TLV is sent in a Notification message.
SHOULD be 1 when the Status TLV is sent in some other message.
Status Code
32-bit unsigned integer encoding the event being signaled. The
structure of a Status Code is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-bit
Error bit. If set (=1), this is a fatal Error Notification. If
clear (=0), this is an Advisory Notification.
F-bit
Forward bit. If set (=1), the notification SHOULD be forwarded
to the Node for the next-hop or previous-hop of the QTP-Path.
If clear (=0), the notification SHOULD NOT be forwarded.
Status Data
30-bit unsigned integer that specifies the status information.
Status Codes are 32-bit unsigned integers with the above encoding.
The Status Codes are defined in this specification.
A Status Code of 0 signals success.
Message ID
If non-zero, 32-bit value that identifies the peer message to
which the Status TLV refers. If zero, no specific peer message is
being identified.
Message Type
If non-zero, the type of the peer message to which the Status TLV
refers. If zero, the Status TLV does not refer to any specific
message type.
3.4 QTP messages
The messages for the QTP procedures are described in following
sections.
The QTP procedures are complex and are difficult to describe fully,
coherently, and unambiguously as a collection of separate message and
Lan, et al. Expires April 2, 2024 [Page 14]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
TLV specifications. Section "QTP Procedures" describes the QTP
procedures in terms of QTP-Path events that may occur at a Node and
how the Node must respond.
All QTP messages have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit
Unknown message bit. When an unknown message is received, if U is
clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored. The
sections following that define messages specify a value for the U-
bit.
Message Type
Identifies the type of message.
Message Length
Specifies the cumulative length in octets of the Message ID and
Parameters.
Message ID
32-bit value used to identify this message. Used by the sending
Node to facilitate identifying Notification messages that may
apply to this message. A Node sending a Notification message in
response to this message SHOULD include this Message ID in the
Status TLV carried by the Notification message; see Section
"Notification Message".
Parameters
Variable length set of required message parameters. Some messages
have no required parameters.
For messages that have required parameters, the required
parameters MUST appear in the order specified by the individual
Lan, et al. Expires April 2, 2024 [Page 15]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
message specifications in the sections that follow. Note that
there is no alignment requirement for the first octet of a QTP
message and that there is no padding at the end of a message; that
is, parameters can end at odd-byte boundaries.
The following message types are defined in this specification:
Message Name Section Title
Notification "Notification Message"
KeepAlive "KeepAlive Message"
PID Request "PID Request Message"
PID Response "PID Response Message"
PID Release "PID Release Message"
The sections that follow specify the encodings and procedures for
these messages.
3.4.1 Notification Message
A Node sends a Notification message to inform its QTP peer of a
significant event. A Notification message signals a fatal error or
provides advisory information such as the outcome of processing a QTP
message.
The encoding for the Notification message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
Status TLV
Indicates the event being signaled. The encoding for the Status
TLV is specified in Section "Status TLV".
ToP TLV
Indicates the ToP associate with the event being signaled. The
Lan, et al. Expires April 2, 2024 [Page 16]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
encoding for the ToP TLV is specified in Section "ToP TLV".
3.4.1.1 Notification Message Procedures
If a Node encounters a condition requiring it to notify its peer with
advisory or error information, it sends the peer a Notification
message containing a Status TLV that encodes the information about
the condition and a ToP TLV indicating the ToP associate the
condition.
If a fatal error occurs, the Status Code carried in the Notification
will indicate that. In this case, after sending the Notification
message the Node SHOULD discard all PID-DestPrefix bindings learned
from the peer.
3.4.1.2 Events Signaled by Notification Messages
For descriptive purpose, it is useful to classify events signaled by
Notification messages into the following categories. Note that the
ToP field is fill with a WildCard ToP TLV if not mentioned in the
following circumstances.
3.4.1.2.1 Malformed PDU or Message
A QTP PDU received on a TCP connection is malformed if:
- The Node Identifier in the PDU header is unknown to the
receiver, or it is known but is not the QTP Identifier
associated by the receiver with the QTP peer. This is a fatal
error signaled by the Bad QTP Identifier Status Code.
- The QTP protocol version is not supported by the receiver. This
is a fatal error signaled by the Bad Protocol Version Status
Code.
- The PDU Length field is too small (< 12) or too large (>maximum
PDU length). This is a fatal error signaled by the Bad PDU
Length Status Code.
A QTP message is malformed if:
- The Message Type is unknown.
If the Message Type is < 0x8000 (high order bit = 0), it is an
error signaled by the Unknown Message Type Status Code.
If the Message Type is >= 0x8000 (high order bit = 1), it is
silently discarded.
Lan, et al. Expires April 2, 2024 [Page 17]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
- The Message Length is too large indicating that the message
extends beyond the end of the containing QTP PDU. This is a
fatal error signaled by the Bad Message Length Status Code.
- The Message Length is too small, that is, smaller than the
smallest possible value component. This is a fatal error
signaled by the Bad Message Length Status Code.
3.4.1.2.2 Unknown or Malformed TLV
A TLV contained in a QTP message received on a TCP connection is
malformed if:
- The TLV Length is too large indicating that the TLV extends
beyond the end of the containing message. This is a fatal error
signaled by the Bad TLV Length Status Code.
- The TLV type is unknown.
If the TLV type is < 0x8000 (high order bit = 0), it is an
error signaled by the Unknown TLV Status Code.
If the TLV type is >= 0x8000 (high order bit = 1), the TLV is
silently dropped.
- The TLV Value is malformed. This occurs when the receiver
handles the TLV but cannot decode the TLV Value. It is a fatal
error signaled by the Malformed TLV Value Status Code.
3.4.1.2.3 Session KeepAlive Timer Expiration
This is a fatal error signaled by the KeepAlive Timer Expired Status
Code.
3.4.1.2.4 Unilateral Connection Shutdown
This is a fatal event signaled by the Shutdown Status Code.
3.4.1.2.5 Events Resulting from Other Messages
Messages may result in events that must be signaled to QTP peers via
Notification messages. These events and the Status Codes used in the
Notification messages to signal them are described in the sections
that describe these messages.
3.4.1.2.6 Internal Errors
A QTP implementation may detect problem conditions specific to its
Lan, et al. Expires April 2, 2024 [Page 18]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
implementation. When such a condition prevents an implementation from
interacting correctly with a peer, the implementation should, when
capable of doing so, use the Internal Error Status Code to signal the
peer. This is a fatal error.
3.4.1.2.7 Miscellaneous Events
These are events that fall into none of the categories above. There
are no miscellaneous events defined in this version of the protocol.
3.4.2 KeepAlive Message
A Node sends KeepAlive messages as part of a mechanism that monitors
the integrity of the TCP connection with another peer.
The encoding for the KeepAlive message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| KeepAlive (0x0101) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
3.4.2.1 KeepAlive Message Procedures
The KeepAlive Timer resets a KeepAlive Timer every time a QTP PDU is
received. The KeepAlive message is provided to allow reset of the
KeepAlive Timer in circumstances where a Node has no other
information to communicate to a peer.
A Node MUST arrange that its peer receive a QTP message of any type
from it at least every KeepAlive Time period. But a KeepAlive message
MUST be sent in circumstances where no other QTP protocol messages
have been sent within the period.
3.4.3 PID Request Message
A Node sends the PID Request message to a peer to request a binding
(mapping) for a DestPrefix. The encoding for the PID Request message
is:
Lan, et al. Expires April 2, 2024 [Page 19]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PID Request (0x0201) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestPrefix TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
DestPrefix TLV
The DestPrefix for which a PID is being requested. See Section
"DestPrefix TLV" for encoding.
ToP TLV
The ToP of the QTP being established. See Section "ToP TLV" for
encoding.
3.4.3.1 PID Request Message Procedures
The Request message is used by an upstream Node to request that the
downstream Node assign and advertise a PID for a DestPrefix of a
specific ToP.
A Node may transmit a Request message under any of the following
conditions:
1. The Node is informed by the management modular (manually or
automatically) to establish a QTP for the given DestPrefix and
the given ToP while it has recognized the DestPrefix via the
forwarding table with the next hop being a QTP peer and the
Node not already having a mapping from the next hop for the
given DestPrefix.
2. The next hop to the DestPrefix changes, and the Node doesn't
already have a mapping from that next hop for the given
DestPrefix.
Note that if the Node already has a pending PID Request message
for the new next hop, it SHOULD NOT issue an additional PID
Request in response to the next hop change.
3. The Node receives a PID Request for a DestPrefix from an
Lan, et al. Expires April 2, 2024 [Page 20]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
upstream peer, the DestPrefix next hop is a QTP peer, and the
Node doesn't already have a mapping from the next hop.
The receiving Node SHOULD respond to a PID Request message with a PID
Response message with a requested PID or with an error status
indicating why it cannot satisfy the request.
When the DestPrefix for which a PID is requested is a DestPrefix, the
receiving Node uses its routing table to determine its response.
Unless its routing table includes an entry that exactly matches the
requested Prefix, the Node MUST respond with a No Route Notification
message.
This version of the protocol defines the following Status Codes for
the Notification message that signals a request cannot be satisfied:
No Route
The DestPrefix for which a PID was requested includes a
DestPrefix for which the Node does not have a route.
No PID Resources
The Node cannot provide a PID because of resource limitations.
When resources become available, the Node MUST notify the
requesting Node by sending a Notification message with the PID
Resources Available Status Code.
See Section "QTP Procedures" for more details.
3.4.4 PID Response Message
A Node sends a PID Response message to a peer to advertise
DestPrefix-PID bindings to the peer.
The encoding for the PID Mapping message is:
Lan, et al. Expires April 2, 2024 [Page 21]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PID Mapping (0x0202) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestPrefix TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
DestPrefix TLV
Specifies the DestPrefix of the DestPrefix-PID mapping being
advertised. See Section " DestPrefix TLVs" for encoding.
ToP TLV
Specifies the ToP of the DestPrefix-PID mapping being advertised.
See Section " ToP TLVs" for encoding.
PID TLV
Specifies the PID component of the DestPrefix-PID mapping. See
Section "PID TLV" for encoding.
3.4.4.1 PID Response Message Procedures
The PID Response message is used by a Node to distribute a PID for a
DestPrefix to a QTP peer.
A Node is responsible for the consistency of the PID mappings it has
distributed and that its peers have these mappings.
A Node receiving a PID Response message from a downstream Node for a
DestPrefix SHOULD NOT use the PID for forwarding unless its routing
table contains an entry that exactly matches the DestPrefix.
See Section "QTP Procedures" for more details.
3.4.5 PID Release Message
An Node sends a PID Release message to an LDP peer to signal the peer
that the Node no longer needs specific DestPrefix-PID mappings
previously requested of and/or advertised by the peer.
Lan, et al. Expires April 2, 2024 [Page 22]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
The encoding for the PID Release Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PID Release (0x0203) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestPrefix TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToP TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
DestPrefix TLV
Identifies the DestPrefix for which the DestPrefix-PID mapping is
being released.
ToP TLV
Identifies the ToP for which the DestPrefix-PID mapping is being
released.
PID TLV
The PID being released (see procedures below).
3.4.5.1 PID Release Message Procedures
A Node transmits a PID Release message to a peer when it no longer
needs a PID previously received from or requested of that peer.
A Node MUST transmit a PID Release message under any of the following
conditions:
1. The Node that sent the PID Response message is no longer the
next hop for the mapped DestPrefix.
2. The Node receives a PID Response message from a Node that is
not the next hop for the DestPrefix.
The DestPrefix TLV specifies the DestPrefix for which PIDs are to be
released. If a WildCard PID TLV is received, all PIDs associated with
the DestPrefix and the ToP are to be released; otherwise, only the
Lan, et al. Expires April 2, 2024 [Page 23]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
PID specified in the PID TLV is to be released.
The DestPrefix TLV may contain the Wildcard DestPrefix; In this case,
if the PID Release message contains a none-WildCard PID TLV, then the
PID is to be released for all DestPrefixes to which it is bound. If
there is a WildCard PID TLV in the PID Release message, then the
sending Node is releasing all PID mappings previously learned from
the receiving peer of the ToP in the message.
See Section "QTP Procedures" for more details.
3.5 Summary
3.5.1 Message Summary
The following are the QTP messages defined in this version of the
protocol.
Message Name Type Section Title
Notification 0x0001 "Notification Message"
KeepAlive 0x0101 "KeepAlive Message"
PID Request 0x0201 "PID Request Message"
PID Response 0x0202 "PID Response Message"
PID Release 0x0203 "PID Release Message"
3.5.2 TLV Summary
The following are the TLVs defined in this version of the protocol.
TLV Type Section Title
DestPrefix 0x0100 "DestPrefix TLV"
PID 0x0200 "PID TLV"
ToP 0x0300 "ToP TLV"
Status 0x0400 "Status TLV"
3.5.3 Status Code Summary
The following are the Status Codes defined in this version of the
protocol.
The "E" column is the required setting of the Status Code E-bit; the
"Status Data" column is the value of the 32-bit Status Data field in
the Status Code TLV.
Status Code E Status Data Section Title
Lan, et al. Expires April 2, 2024 [Page 24]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
Success 0 0x00000000 "Status TLV"
Bad LDP Identifier 1 0x00000001 "Events Signaled by ..."
Bad Protocol Version 1 0x00000002 "Events Signaled by ..."
Bad PDU Length 1 0x00000003 "Events Signaled by ..."
Unknown Message Type 0 0x00000004 "Events Signaled by ..."
Bad Message Length 1 0x00000005 "Events Signaled by ..."
Unknown TLV 0 0x00000006 "Events Signaled by ..."
Bad TLV Length 1 0x00000007 "Events Signaled by ..."
Malformed TLV Value 1 0x00000008 "Events Signaled by ..."
Shutdown 1 0x00000009 "Events Signaled by ..."
Unknown DestPrefix 0 0x0000000A "DestPrefix TLV"
No Route 0 0x0000000B "PID Request Message"
No PID Resources 0 0x0000000C "PID Request Message"
PID Resources/ 0 0x0000000D "PID Request Message"
Available
KeepAlive Timer/ 1 0x0000000E "Events Signaled by ..."
Expired
Unsupported Address/ 0 0x0000000F "DestPrefix TLV"
Family
Internal Error 1 0x00000010 "Events Signaled by ..."
4 QTP Procedure
4.1 Establishment of QTP-Path
4.1.1 The trigger condition of QTP-Path establishing
When the business is running in the virtual network, the data can be
transmitted through QTP-Path. After the management plane determines
establish QTP-Path between two nodes, it carries out the process of
QTP-Path establishing through the control plane. The determination of
QTP-Path establishing can be obtained through the management plane's
gathering business requests and the perception of network status, or
the network administrator manually configures. Once the establishment
determination is made, the control plane needs the parameters of QTP-
Path, i.e. source node, destination node, flow types and so on, after
obtaining those parameters, the control plane will establish and
maintain QTP-Path according to the protocol.
4.1.2 Path establishment process
Path establishment start from the source node, and sends request
message hop by hop. The node receives the message and judges if it
meets the requests, if no, the node sends warning message reversely,
else it continues to send request message to the next node until to
the destination node. The destination node sends reply message
reversely along the path to the source node, the establishment of
QTP-Path is successful. This section describes the establishment
Lan, et al. Expires April 2, 2024 [Page 25]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
process in detail.
A Node processes a received PID Request message as follows:
1. The Node looks up in the local routing table for the next hop
of DestPrefix. If the node can not find the next hop, it sends
Notification message of "No Route", and the process goes to 8.
2. Check whether the node has established TCP connection with the
next hop, if not, this node initiates a request for
establishing the TCP connection, and after the connection is
done, start KeepAlive timer. If the connection can not be
established, then the node sends Notification message of
"ShutDown", and the process goes to 8.
3. Check whether PIB consists tables of DestPrefix and ToP, and
judges whether the next hop in PIB is the one in routing
tables:
a. If so, insert the PID value of the table to PID Response
Message, and forward the message to the upstream node, then
the process goes to 8.
b. If not,insert the PID value of the table to PID Release,and
forward the message to the next hop, then delete the table.
4. Check whether this node supports ToP traffic forwarding, if
not, forward Notification message of " Internal Error" to the
upstream node, then the process goes to 8.
5. Check whether this node has residual PIDs, if not, forward
Notification message of " No PID Resources" to the upstream
node, then the process goes to 8.
6. Forward the message of PID Request message to the next hop, and
wait to receive the downstream message.
7. The reply message received from the downstream nodes:
a. If the message is PID Response, insert new tables which
consist of DestPrefix, ToP, PID, NextPID, Nexthop etc.to PIB
according to the PID value in reply message. Insert the PID
value locally generated to PID Response Message, and forward
the message to upstream nodes.
b. If the message is Notification, then forward the message to
upstream nodes
Lan, et al. Expires April 2, 2024 [Page 26]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
8. Over
4.2. Removal of the QTP-Path
4.2.1 The trigger condition of removal process
When the management plane determines to remove QTP-Path between two
nodes, it carries out the removal process of QTP-Path through the
control plane. The determination of QTP-Path removal can be obtained
through the perception of network status and learning, or the network
administrator manually configures. After the removal determination is
made, the management plane gives the source node, destination node
and business types, in this way, the control plane can carry out the
removal process successfully.
4.2.2 QTP-Path removal process
The removal of QTP-Path starts from the source node and sends removal
message along the path.
The procedure in which node processes PID Release message is as
follows:
1. If the message comes from upstream nodes, forward it to
downstream nodes; if it comes from downstream nodes; forward it
to upstream nodes.
2. If the value of PID equals to the value of WildCard, delete the
tables in PIB which meets DestPrefix and ToP, else delete the
tables in PIB which meets DestPrefix, ToP and PID
4.3. QTP-Path adjustment process
4.3.1 The trigger condition of QTP-Path adjustment
When the management plane determines to adjust QTP-Path between two
nodes, it carries out the adjustment process of QTP-Path through the
control plane. The determination of QTP-Path adjustment can be
obtained through the management plane's gathering business requests
and the perception of network status, or the network administrator
manually configures. Under the two conditions below, the management
plane will adjust QTP-Path:
1. A link of QTP-Path fails.
2. A link or a section of QTP-Path congests, resulting in that
data transmission can not meet business needs. Once the
adjustment determination is made, the control plane needs the
Lan, et al. Expires April 2, 2024 [Page 27]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
parameters of QTP-Path, e.g. source node, destination node,
business types etc., after obtaining those parameters, the
control plane will adjust QTP-Path according to the protocol.
4.3.2 QTP-Path Adjustment Process
When the management plane determines to adjust QTP-Path between two
nodes, it sends QTP-Path establishment message to source nodes, then
the source node sends PID Request message to downstream nodes. The
adjustment process is similar to the establishment process. Because
the adjustment of QTP-Path is based on the link availability or QoS
performance, the adjustment process depends on the routing protocol
on the node.
5 Security Considerations
TBA.
6 IANA Considerations
This memo includes no request to IANA.
7 References
7.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August
2006.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A.,
Venkataramaiah, N., Wang, Y., Duda, K., Ganga, I., Lin,
G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE:
Network Virtualization using Generic Routing
Encapsulation", draft-sridharan-virtualization-nvgre-02
(work in progress), February 2013.
7.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
Lan, et al. Expires April 2, 2024 [Page 28]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
Authors' Addresses
Julong Lan
National Digital Switching System Engineering and Technological
Research Center
NDSC, No.7 , Jianxue Street,Jinshui District
Zhengzhou, 450002
P.R.China
Phone: +86-371-8163-2988
Email: ndscljl@163.com
URI: http://www.ndsc.com.cn/
Dongnian Cheng
National Digital Switching System Engineering and Technological
Research Center
NDSC, No.7 , Jianxue Street,Jinshui District
Zhengzhou, 450002
P.R.China
Phone: +86-371-8163-2743
Email: cdn@mail.ndsc.com.cn
URI: http://www.ndsc.com.cn/
Yuxiang Hu
National Digital Switching System Engineering and Technological
Research Center
NDSC, No.7 , Jianxue Street,Jinshui District
Zhengzhou, 450002
P.R.China
Phone: +86-371-8163-2737
Email: chxachxa@126.com
Guozhen Cheng
National Digital Switching System Engineering and Technological
Lan, et al. Expires April 2, 2024 [Page 29]
INTERNET DRAFT QoS-level aware Transmission Protocol October 2, 2023
Research Center
NDSC, No.7 , Jianxue Street,Jinshui District
Zhengzhou, 450002
P.R.China
Phone: +86-371-8163-2725
Email: chengguozhen1986@163.com
Tong Duan
National Digital Switching System Engineering and Technological
Research Center
NDSC, No.7 , Jianxue Street,Jinshui District
Zhengzhou, 450002
P.R.China
Phone: +86-371-8163-2846
Email: duantong21@126.com
Lan, et al. Expires April 2, 2024 [Page 30]
