idnits 2.17.1 draft-lan-nvo3-qtp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 27, 2018) is 2030 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KEYWORDS' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC4594' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 1256, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1269, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1272, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1275, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4594 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-02 ** Downref: Normative reference to an Informational draft: draft-sridharan-virtualization-nvgre (ref. 'I-D.sridharan-virtualization-nvgre') Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Lan 2 Intended Status: Proposed Standard D. Cheng 3 Expires: March 27, 2019 Y. Hu 4 G. Cheng 5 T. Duan 6 National Digital Switching System Engineering and Technological 7 Research Center, P.R.China 8 September 27, 2018 10 QoS-level aware Transmission Protocol (QTP) for virtual networks 11 draft-lan-nvo3-qtp-08 13 Abstract 15 This document provides a QoS-level aware Transmission Protocol (QTP) 16 for virtual networks. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Motivation and background . . . . . . . . . . . . . . . . . 4 58 1.2 QTP-path . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3 QTP Overview . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.5 Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5 62 2 QTP Data Encapsulation Specification . . . . . . . . . . . . . 5 63 2.1 QTP Header Specification . . . . . . . . . . . . . . . . . 5 64 2.2 QTP Data Encapsulation . . . . . . . . . . . . . . . . . . 6 65 3 QTP Message Specification . . . . . . . . . . . . . . . . . . . 7 66 3.1 Destination Prefix and Node Identifiers . . . . . . . . . . 8 67 3.1.1 Destination Prefix (DestPrefix) . . . . . . . . . . . . 8 68 3.1.2 Node Identifiers . . . . . . . . . . . . . . . . . . . . 8 69 3.2 QTP PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3 TLV Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3.1 DestPrefix TLV . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.2 PID TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.3.3 ToP TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.3.4 Status TLV . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.4 QTP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.4.1 Notification Message . . . . . . . . . . . . . . . . . . 16 77 3.4.1.1 Notification Message Procedures . . . . . . . . . . 17 78 3.4.1.2 Events Signaled by Notification Messages . . . . . . 17 79 3.4.2 KeepAlive Message . . . . . . . . . . . . . . . . . . . 19 80 3.4.2.1 KeepAlive Message Procedures . . . . . . . . . . . . 19 81 3.4.3 PID Request Message . . . . . . . . . . . . . . . . . . 19 82 3.4.3.1 PID Request Message Procedures . . . . . . . . . . . 20 83 3.4.4 PID Response Message . . . . . . . . . . . . . . . . . . 21 84 3.4.4.1 PID Response Message Procedures . . . . . . . . . . 22 85 3.4.5 PID Release Message . . . . . . . . . . . . . . . . . . 22 86 3.4.5.1 PID Release Message Procedures . . . . . . . . . . . 23 87 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 3.5.1 Message Summary . . . . . . . . . . . . . . . . . . . . 24 89 3.5.2 TLV Summary . . . . . . . . . . . . . . . . . . . . . . 24 90 3.5.3 Status Code Summary . . . . . . . . . . . . . . . . . . 24 91 4 QTP Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 4.1 Establishment of QTP-Path . . . . . . . . . . . . . . . . . 25 93 4.1.1 The trigger condition of QTP-Path establishing . . . . . 25 94 4.1.2 Path establishment process . . . . . . . . . . . . . . . 25 95 4.2. Removal of the QTP-Path . . . . . . . . . . . . . . . . . . 27 96 4.2.1 The trigger condition of removal process . . . . . . . . 27 97 4.2.2 QTP-Path removal process . . . . . . . . . . . . . . . . 27 98 4.3. QTP-Path adjustment process . . . . . . . . . . . . . . . . 27 99 4.3.1 The trigger condition of QTP-Path adjustment . . . . . . 27 100 4.3.2 QTP-Path Adjustment Process . . . . . . . . . . . . . . 28 101 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 28 102 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 103 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 7.1 Normative References . . . . . . . . . . . . . . . . . . . 28 105 7.2 Informative References . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 108 1 Introduction 110 1.1 Motivation and background 112 Virtual network has been designed to implement all types of network, 113 to achieve scalability in today's Internet, for example, multi- 114 tenants sharing network in data center network. This document 115 provides a QoS-level aware Transmission Protocol (QTP) for virtual 116 networks. Since virtual network transmits data in the form of "best 117 effort" under today's connectionless network, its performance cannot 118 be guaranteed. In addition, due to the elasticity of network traffic, 119 virtual networks sharing the same physical network cannot achieve 120 minimum resource guarantee and fairness under network congestion. QTP 121 constructs various data transmission tunnels, namely, QTP-path, for 122 different virtual networks that have special requests. We embed a 123 field named QTP-path identifier (PID) in QTP header, and explicitly 124 contains QoS level to indicate the resource level sharing when data 125 transmission. 127 1.2 QTP-path 129 The applications on the virtual network always originate requirements 130 that have identical path and performance. Therefore, QTP aggregates 131 these requirements, and constructs one data transmission tunnel to 132 maximize network throughput. The tunnel, we say, QTP-path is labeled 133 by a QoS level according with the requests in the protocol header. 135 1.3 QTP Overview 137 We assume that all the network nodes can handle global knowledge 138 about network loads and application requests. If there are several 139 pairs in network originate requests for identical QoS level and have 140 common in path, then the management plane decides to establish a QTP- 141 path in the common part of the path. Firstly, the starting node 142 assign a PID to the path, and send QTP-path establish request. Then 143 the relative nodes on the path update their path information base 144 (PIB) which storage the PIDs of QTP-paths across it. Finally, when 145 the QTP-path has been established, the data transmitted over it can 146 be transfer based on PIB matching PID in PDUs, and realize QoS level 147 guarantee. 149 1.4 Terminology 151 QTP-path the tunnel established for the same requests by 152 QTP can be used to transmission data. 153 QTP-path identifier represented as a 32-bit number in a 4 octet field 154 Node Identifier a four octet quantity used to identify an 155 QTP Node. 157 1.5 Acronyms and Abbreviations 158 PDU protocol data unit 159 TTL Time to live 160 ToP Type of QTP-path 161 PID QTP-path Identifier 162 TTL Time to live 163 TLV Type-Length-Value 164 PIB QTP-path information base 166 2 QTP Data Encapsulation Specification 168 2.1 QTP Header Specification 170 Each packet over QTP-path MUST have a QTP header. The QTP header is 171 represented by 4 octets. This is shown in Figure 1. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ToP | PID | TTL | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 ToP: Type of QTP-path, 6 bits 180 PID: QTP-path Identifier, 18 bits 181 TTL: Time to live, 8 bits 183 Figure 1 185 The QTP header appears AFTER the data link layer header, but BEFORE 186 any network layer header. Each QTP header is broken down into the 187 following fields: 189 o Type of QTP-path (ToP) 191 This six-bit field is used to identify the type of QTP-path. 192 Each type of QTP-path SHALL carry only one class of traffic. RFC 193 4594 has defined twelve different classes of traffic, namely, 194 network control, telephony, signaling, multimedia conferencing, 195 real-time interactive, multimedia streaming, broadcast video, 196 low-latency data, OAM, high-throughput data, standard, and low- 197 priority data. End-to-end quantitative performance requirements 198 may be obtained from ITU-T Recommendations Y.1541 and Y.1540. It 199 is RECOMMENDED that the value of ToP be the same with DSCP 200 value. 202 o QTP-path Identifier (PID) 204 This 18-bit field carries the actual value of the QTP-Path 205 identifier. When a QTP-path packet is received, the PID value is 206 looked up to obtain the next hop to which the packet is to be 207 forwarded. Before forwarding, the PID may be replaced with 208 another, or be popped off with the whole QTP-path header. 210 o Time to live (TTL) 212 This eight-bit field is used to encode a time-to-live value. The 213 processing of this field is the same with that of MPLS TTL field 214 in RFC 3032. 216 Different types of QTP-paths MUST have different behaviors on QoS 217 guarantee and resource allocation to achieve their required traffic 218 characteristics. 220 2.2 QTP Data Encapsulation 222 The packet format for QTP-path is shown in Figure 2. 224 QTP header encapsulation is used to realize a QTP-path, and the 225 header by definition in section 2.1 contains a ToP, a PID, and a TTL. 227 NVGRE encapsulation is used to realize an overlay virtual network. 228 The virtual network identifier is carried as the 24-bit VSID in the 229 NVGRE header. 231 0 1 2 3 232 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 233 Outer Ethernet Header: 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Outer Destination MAC Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Outer Destination MAC Address | Outer Source MAC Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Outer Source MAC Address | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Ethertype = 0x01FF | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Outer QTP Header: 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | ToP | PID | TTL | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Outer IPv4 Header: 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |Version| IHL |Type of Service| Total Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Identification |Flags| Fragment Offset | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Time to Live | Protocol=0x2F | Header Checksum | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Outer Source IPv4 Address | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Outer Destination IPv4 Address | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 NVGRE Encapsulation: 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 | NVGRE Encapsulation | 263 | (include NVGRE Header, Original Inner Ethernet Frame) | 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Frame Check Sequence: 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2 273 The QTP data encapsulation includes the outer Ethernet header, the 274 QTP-path header, the outer IPv4 header, and the NVGRE encapsulation: 276 o Outer Ethernet header: The source MAC address in the outer frame 277 is set to the MAC address associated with the NVGRE endpoint. The 278 destination MAC address is set to the MAC address of the nexthop 279 IP address for the destination NVE. The EtherType field is set to 280 0x01FF which is reserved for experimental use. 282 o QTP header: The ToP is used to identify the type of QTP-path, 283 the PID is used to identify the QTP-path, and the TTL is used to 284 record the time to live for the QTP-path. 286 o Outer IPv4 header: IPv4 is used as the delivery protocol for 287 NVGRE. The protocol field in the IPv4 header is set to 0x2F. The 288 IP address in the outer frame is referred to as the Provider 289 Address (PA). 291 o NVGRE encapsulation: It includes NVGRE header, and original 292 inner Ethernet frame. The VSID in NVGRE header can be used to 293 identify the different virtual networks. The original inner 294 Ethernet frame comprises of an inner Ethernet header followed by 295 the inner IP header, followed by the IP payload. 297 3 QTP Message Specification 299 QTP message exchanges are accomplished by sending QTP protocol data 300 units (PDUs) over TCP connections. Each QTP PDU can carry one or more 301 QTP messages. Note that the messages in a QTP PDU need not be related 302 to one another. For example, a single PDU could carry a PID Request 303 message, another message for PID Responding message, and a third 304 Notification message that signals some event. 306 3.1 Destination Prefix and Node Identifiers 308 3.1.1 Destination Prefix (DestPrefix) 310 A DestPrefix specification for each QTP-Path is provided to precisely 311 specify which packets may be mapped to each QTP-Path. The DestPrefix 312 identifies the set of IP packets that may be mapped to that QTP-Path. 314 This specification defines DestPrefix as an address prefix of any 315 length from 0 to a full address, inclusive. We give the rules used 316 for mapping packets to QTP-Path that have been set up using a 317 DestPrefix in the remainder of this section. 319 We say that a particular address matches a particular address prefix 320 if and only if that address begins with that prefix. We also say that 321 a particular packet matches a particular QTP-Path if and only if the 322 packet's destination address matches the DestPrefix of that QTP-Path. 324 The following rules describe the procedure for mapping a particular 325 packet to a particular QTP-Path. 327 - If a packet matches exactly one QTP-Path, the packet is mapped 328 to that QTP-Path. 330 - If a packet matches multiple QTP-Paths, it is mapped to the 331 QTP-Path whose matching DestPrefix is the longest. 333 - If it is known that a packet must traverse a particular egress 334 router, and there is a QTP-Path with a DestPrefix that is a /32 335 address of that router, then the packet is mapped to that QTP- 336 Path. 338 3.1.2 Node Identifiers 340 A Node Identifier is a four octet quantity used to identify a QTP 341 Node. The Node Identifier must be a globally unique value, such as a 342 32-bit router Id assigned to the QTP Node. 344 3.2 QTP PDU 346 Each QTP PDU consists of a QTP header and one or more QTP messages. 347 The QTP header is: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Version | PDU Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Node Identifier | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Version 358 Two octet unsigned integer containing the version number of the 359 protocol. This version of the specification specifies QTP 360 protocol version 1. 362 PDU Length 363 Two octet integer specifying the total length of this PDU in 364 octets, excluding the Version and PDU Length fields. 366 Node Identifier 367 Four octet field that uniquely identifies the node and MUST be a 368 globally unique value. It SHOULD be a 32-bit router Id assigned to 369 the Node . 371 3.3 TLV Encoding 373 QTP uses a Type-Length-Value (TLV) encoding scheme to encode the 374 information carried in QTP messages. 376 A QTP TLV is encoded as a 2 octet field that uses 15 bits to specify 377 a Type and 1 bits to specify behavior when a Node doesn't recognize 378 the Type, followed by a 2 octet Length field, followed by a variable 379 length Value field. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |U| Type | Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 | Value | 388 ~ ~ 389 | | 390 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 U-bit 395 Unknown TLV bit. When an unknown TLV is recieved, if U is 396 clear(=0), a notification MUST be returned to the message 397 originator and the entire message MUST be ignored; if U is set 398 (=1), the unknown TLV MUST be silently ignored and the rest of the 399 message processed as if the unknown TLV did not exist. 401 Type 402 Encodes how the Value field is to be interpreted. 404 Length 405 Specifies the length of the Value field in octets. 407 Value 408 Octet string of Length octets that encodes information to be 409 interpreted as specified by the Type field. 411 Note that there is no alignment requirement for the first octet of a 412 TLV. TLVs may be nested, that is the Value field itself may contain 413 TLV encodings. 415 The TLV encoding scheme is very general. In principle, everything in 416 a QTP PDU could be encoded as a TLV. Note that the TLV scheme is not 417 used to its full generality in this specification. 419 The specification assigns type values for related TLVs, such as the 420 PID TLVs, from a contiguous block in the 16-bit TLV type number 421 space. Section "TLV Summary" lists the TLVs defined in this version 422 of the protocol. 424 In this section, the TLV encodings for some commonly used parameters 425 are specified. 427 3.3.1 DestPrefix TLV 429 PIDs are bound to DestPrefixes. A DestPrefix TLV encodes a list of 430 one or more DestPrefix Items. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |0| DestPrefix (0x0100) | Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | DestPrefix Item 1 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 ~ ~ 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | DestPrefix Item n | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 DestPrefix Item 1 to DestPrefix Item n 447 The DestPrefix Item encoding depends on the type of DestPrefix. 449 A DestPrefix value is encoded as a 1 octet field that specifies 450 the element type, and a variable length field that is the type- 451 dependent DestPrefix value. 453 The DestPrefix value encoding is: 455 DestPrefix Type Value type name 457 Wildcard 0x01 No value; i.e., 0 value octets; 458 See below. 460 Prefix 0x02 See below. 462 Wildcard DestPrefix 463 To be used only in the PID Release messages indicating that the 464 release is to be applied to all DestPrefixes associated with 465 the PID within the following PID TLV. Must be the only 466 DestPrefix Item in the DestPrefix TLV. 468 DestPrefix value encoding: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Prefix (2) | Address Family | PreLen | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Prefix | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Address Family 479 Two octet quantity containing a value from ADDRESS FAMILY 480 NUMBERS in [ASSIGNED_AF] that encodes the address family for 481 the address prefix in the Prefix field. 483 PreLen 484 One octet unsigned integer containing the length in bits of the 485 address prefix that follows. A length of zero indicates a 486 prefix that matches all addresses (the default destination), in 487 this case, the Prefix itself is zero octets. 489 Prefix 490 An address prefix encoded according to the Address Family 491 field, whose length was specified in bits in the PreLen field, 492 padded to a byte boundary. 494 When decoding a DestPrefix TLV, if a Node encounters a DestPrefix 495 with an Address Family it does not support, it SHOULD stop decoding 496 the DestPrefix TLV, abort processing the message containing the TLV, 497 and send an "Unsupported Address Family" Notification message to its 498 QTP peer. If a Node encounters a DestPrefix type it cannot decode, it 499 SHOULD stop decoding the DestPrefix TLV, abort processing the message 500 containing the TLV, and send an "Unknown DestPrefix " Notification 501 message to its QTP peer. 503 3.3.2 PID TLV 505 A PID TLV are used to encode a PID. The encoding for PID TLV is: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |0| PID (0x0200) | Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | PID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 PID 516 This is a 18-bit PID value represented as a 18-bit number in a 4 517 octet field as follows: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | PID | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 3.3.3 ToP TLV 527 When establishing a QTP-Path, a ToP TLV is used to specify type of 528 QTP-Path and the QoS guarantee feature of the QTP. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |0| ToP (0x0300) | Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | ToP | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 ToP 539 This is a 6-bit ToP value represented as a 6-bit number in a 4 540 octet field as follows: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | ToP | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 A ToP TLV with Length 0 is a WildCard ToP. 550 3.3.4 Status TLV 552 Status TLVs are carried in Notification messages to specify events 553 being signaled. The encoding for the Status TLV is: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |U| Status (0x0400) | Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Status Code | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Message ID | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Message Type | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 U-bit 567 SHOULD be 0 when the Status TLV is sent in a Notification message. 568 SHOULD be 1 when the Status TLV is sent in some other message. 570 Status Code 571 32-bit unsigned integer encoding the event being signaled. The 572 structure of a Status Code is: 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |E|F| Status Data | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 E-bit 581 Error bit. If set (=1), this is a fatal Error Notification. If 582 clear (=0), this is an Advisory Notification. 584 F-bit 585 Forward bit. If set (=1), the notification SHOULD be forwarded 586 to the Node for the next-hop or previous-hop of the QTP-Path. 587 If clear (=0), the notification SHOULD NOT be forwarded. 589 Status Data 590 30-bit unsigned integer that specifies the status information. 592 Status Codes are 32-bit unsigned integers with the above encoding. 593 The Status Codes are defined in this specification. 595 A Status Code of 0 signals success. 597 Message ID 598 If non-zero, 32-bit value that identifies the peer message to 599 which the Status TLV refers. If zero, no specific peer message is 600 being identified. 602 Message Type 603 If non-zero, the type of the peer message to which the Status TLV 604 refers. If zero, the Status TLV does not refer to any specific 605 message type. 607 3.4 QTP messages 609 The messages for the QTP procedures are described in following 610 sections. 612 The QTP procedures are complex and are difficult to describe fully, 613 coherently, and unambiguously as a collection of separate message and 614 TLV specifications. Section "QTP Procedures" describes the QTP 615 procedures in terms of QTP-Path events that may occur at a Node and 616 how the Node must respond. 618 All QTP messages have the following format: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |U| Message Type | Message Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Message ID | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 + + 629 | Parameters | 630 + + 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 U-bit 635 Unknown message bit. When an unknown message is received, if U is 636 clear (=0), a notification is returned to the message originator; 637 if U is set (=1), the unknown message is silently ignored. The 638 sections following that define messages specify a value for the U- 639 bit. 641 Message Type 642 Identifies the type of message. 644 Message Length 645 Specifies the cumulative length in octets of the Message ID and 646 Parameters. 648 Message ID 649 32-bit value used to identify this message. Used by the sending 650 Node to facilitate identifying Notification messages that may 651 apply to this message. A Node sending a Notification message in 652 response to this message SHOULD include this Message ID in the 653 Status TLV carried by the Notification message; see Section 654 "Notification Message". 656 Parameters 657 Variable length set of required message parameters. Some messages 658 have no required parameters. 660 For messages that have required parameters, the required 661 parameters MUST appear in the order specified by the individual 662 message specifications in the sections that follow. Note that 663 there is no alignment requirement for the first octet of a QTP 664 message and that there is no padding at the end of a message; that 665 is, parameters can end at odd-byte boundaries. 667 The following message types are defined in this specification: 669 Message Name Section Title 671 Notification "Notification Message" 672 KeepAlive "KeepAlive Message" 673 PID Request "PID Request Message" 674 PID Response "PID Response Message" 675 PID Release "PID Release Message" 677 The sections that follow specify the encodings and procedures for 678 these messages. 680 3.4.1 Notification Message 682 A Node sends a Notification message to inform its QTP peer of a 683 significant event. A Notification message signals a fatal error or 684 provides advisory information such as the outcome of processing a QTP 685 message. 687 The encoding for the Notification message is: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |0| Notification (0x0001) | Message Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Message ID | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Status (TLV) | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | ToP (TLV) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Message ID 702 32-bit value used to identify this message. 704 Status TLV 705 Indicates the event being signaled. The encoding for the Status 706 TLV is specified in Section "Status TLV". 708 ToP TLV 709 Indicates the ToP associate with the event being signaled. The 710 encoding for the ToP TLV is specified in Section "ToP TLV". 712 3.4.1.1 Notification Message Procedures 714 If a Node encounters a condition requiring it to notify its peer with 715 advisory or error information, it sends the peer a Notification 716 message containing a Status TLV that encodes the information about 717 the condition and a ToP TLV indicating the ToP associate the 718 condition. 720 If a fatal error occurs, the Status Code carried in the Notification 721 will indicate that. In this case, after sending the Notification 722 message the Node SHOULD discard all PID-DestPrefix bindings learned 723 from the peer. 725 3.4.1.2 Events Signaled by Notification Messages 727 For descriptive purpose, it is useful to classify events signaled by 728 Notification messages into the following categories. Note that the 729 ToP field is fill with a WildCard ToP TLV if not mentioned in the 730 following circumstances. 732 3.4.1.2.1 Malformed PDU or Message 734 A QTP PDU received on a TCP connection is malformed if: 736 - The Node Identifier in the PDU header is unknown to the 737 receiver, or it is known but is not the QTP Identifier 738 associated by the receiver with the QTP peer. This is a fatal 739 error signaled by the Bad QTP Identifier Status Code. 741 - The QTP protocol version is not supported by the receiver. This 742 is a fatal error signaled by the Bad Protocol Version Status 743 Code. 745 - The PDU Length field is too small (< 12) or too large (>maximum 746 PDU length). This is a fatal error signaled by the Bad PDU 747 Length Status Code. 749 A QTP message is malformed if: 751 - The Message Type is unknown. 753 If the Message Type is < 0x8000 (high order bit = 0), it is an 754 error signaled by the Unknown Message Type Status Code. 756 If the Message Type is >= 0x8000 (high order bit = 1), it is 757 silently discarded. 759 - The Message Length is too large indicating that the message 760 extends beyond the end of the containing QTP PDU. This is a 761 fatal error signaled by the Bad Message Length Status Code. 763 - The Message Length is too small, that is, smaller than the 764 smallest possible value component. This is a fatal error 765 signaled by the Bad Message Length Status Code. 767 3.4.1.2.2 Unknown or Malformed TLV 769 A TLV contained in a QTP message received on a TCP connection is 770 malformed if: 772 - The TLV Length is too large indicating that the TLV extends 773 beyond the end of the containing message. This is a fatal error 774 signaled by the Bad TLV Length Status Code. 776 - The TLV type is unknown. 778 If the TLV type is < 0x8000 (high order bit = 0), it is an 779 error signaled by the Unknown TLV Status Code. 781 If the TLV type is >= 0x8000 (high order bit = 1), the TLV is 782 silently dropped. 784 - The TLV Value is malformed. This occurs when the receiver 785 handles the TLV but cannot decode the TLV Value. It is a fatal 786 error signaled by the Malformed TLV Value Status Code. 788 3.4.1.2.3 Session KeepAlive Timer Expiration 790 This is a fatal error signaled by the KeepAlive Timer Expired Status 791 Code. 793 3.4.1.2.4 Unilateral Connection Shutdown 795 This is a fatal event signaled by the Shutdown Status Code. 797 3.4.1.2.5 Events Resulting from Other Messages 799 Messages may result in events that must be signaled to QTP peers via 800 Notification messages. These events and the Status Codes used in the 801 Notification messages to signal them are described in the sections 802 that describe these messages. 804 3.4.1.2.6 Internal Errors 806 A QTP implementation may detect problem conditions specific to its 807 implementation. When such a condition prevents an implementation from 808 interacting correctly with a peer, the implementation should, when 809 capable of doing so, use the Internal Error Status Code to signal the 810 peer. This is a fatal error. 812 3.4.1.2.7 Miscellaneous Events 814 These are events that fall into none of the categories above. There 815 are no miscellaneous events defined in this version of the protocol. 817 3.4.2 KeepAlive Message 819 A Node sends KeepAlive messages as part of a mechanism that monitors 820 the integrity of the TCP connection with another peer. 822 The encoding for the KeepAlive message is: 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 |0| KeepAlive (0x0101) | Message Length | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Message ID | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Message ID 833 32-bit value used to identify this message. 835 3.4.2.1 KeepAlive Message Procedures 837 The KeepAlive Timer resets a KeepAlive Timer every time a QTP PDU is 838 received. The KeepAlive message is provided to allow reset of the 839 KeepAlive Timer in circumstances where a Node has no other 840 information to communicate to a peer. 842 A Node MUST arrange that its peer receive a QTP message of any type 843 from it at least every KeepAlive Time period. But a KeepAlive message 844 MUST be sent in circumstances where no other QTP protocol messages 845 have been sent within the period. 847 3.4.3 PID Request Message 849 A Node sends the PID Request message to a peer to request a binding 850 (mapping) for a DestPrefix. The encoding for the PID Request message 851 is: 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |0| PID Request (0x0201) | Message Length | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Message ID | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | DestPrefix TLV | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | ToP TLV | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Message ID 866 32-bit value used to identify this message. 868 DestPrefix TLV 869 The DestPrefix for which a PID is being requested. See Section 870 "DestPrefix TLV" for encoding. 872 ToP TLV 873 The ToP of the QTP being established. See Section "ToP TLV" for 874 encoding. 876 3.4.3.1 PID Request Message Procedures 878 The Request message is used by an upstream Node to request that the 879 downstream Node assign and advertise a PID for a DestPrefix of a 880 specific ToP. 882 A Node may transmit a Request message under any of the following 883 conditions: 885 1. The Node is informed by the management modular (manually or 886 automatically) to establish a QTP for the given DestPrefix and 887 the given ToP while it has recognized the DestPrefix via the 888 forwarding table with the next hop being a QTP peer and the 889 Node not already having a mapping from the next hop for the 890 given DestPrefix. 892 2. The next hop to the DestPrefix changes, and the Node doesn't 893 already have a mapping from that next hop for the given 894 DestPrefix. 896 Note that if the Node already has a pending PID Request message 897 for the new next hop, it SHOULD NOT issue an additional PID 898 Request in response to the next hop change. 900 3. The Node receives a PID Request for a DestPrefix from an 901 upstream peer, the DestPrefix next hop is a QTP peer, and the 902 Node doesn't already have a mapping from the next hop. 904 The receiving Node SHOULD respond to a PID Request message with a PID 905 Response message with a requested PID or with an error status 906 indicating why it cannot satisfy the request. 908 When the DestPrefix for which a PID is requested is a DestPrefix, the 909 receiving Node uses its routing table to determine its response. 910 Unless its routing table includes an entry that exactly matches the 911 requested Prefix, the Node MUST respond with a No Route Notification 912 message. 914 This version of the protocol defines the following Status Codes for 915 the Notification message that signals a request cannot be satisfied: 917 No Route 918 The DestPrefix for which a PID was requested includes a 919 DestPrefix for which the Node does not have a route. 921 No PID Resources 922 The Node cannot provide a PID because of resource limitations. 923 When resources become available, the Node MUST notify the 924 requesting Node by sending a Notification message with the PID 925 Resources Available Status Code. 927 See Section "QTP Procedures" for more details. 929 3.4.4 PID Response Message 931 A Node sends a PID Response message to a peer to advertise 932 DestPrefix-PID bindings to the peer. 934 The encoding for the PID Mapping message is: 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |0| PID Mapping (0x0202) | Message Length | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Message ID | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | DestPrefix TLV | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | ToP TLV | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | PID TLV | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Message ID 951 32-bit value used to identify this message. 953 DestPrefix TLV 954 Specifies the DestPrefix of the DestPrefix-PID mapping being 955 advertised. See Section " DestPrefix TLVs" for encoding. 957 ToP TLV 958 Specifies the ToP of the DestPrefix-PID mapping being advertised. 959 See Section " ToP TLVs" for encoding. 961 PID TLV 962 Specifies the PID component of the DestPrefix-PID mapping. See 963 Section "PID TLV" for encoding. 965 3.4.4.1 PID Response Message Procedures 967 The PID Response message is used by a Node to distribute a PID for a 968 DestPrefix to a QTP peer. 970 A Node is responsible for the consistency of the PID mappings it has 971 distributed and that its peers have these mappings. 973 A Node receiving a PID Response message from a downstream Node for a 974 DestPrefix SHOULD NOT use the PID for forwarding unless its routing 975 table contains an entry that exactly matches the DestPrefix. 977 See Section "QTP Procedures" for more details. 979 3.4.5 PID Release Message 981 An Node sends a PID Release message to an LDP peer to signal the peer 982 that the Node no longer needs specific DestPrefix-PID mappings 983 previously requested of and/or advertised by the peer. 985 The encoding for the PID Release Message is: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 |0| PID Release (0x0203) | Message Length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Message ID | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | DestPrefix TLV | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | ToP TLV | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | PID TLV | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 Message ID 1002 32-bit value used to identify this message. 1004 DestPrefix TLV 1005 Identifies the DestPrefix for which the DestPrefix-PID mapping is 1006 being released. 1008 ToP TLV 1009 Identifies the ToP for which the DestPrefix-PID mapping is being 1010 released. 1012 PID TLV 1013 The PID being released (see procedures below). 1015 3.4.5.1 PID Release Message Procedures 1017 A Node transmits a PID Release message to a peer when it no longer 1018 needs a PID previously received from or requested of that peer. 1020 A Node MUST transmit a PID Release message under any of the following 1021 conditions: 1023 1. The Node that sent the PID Response message is no longer the 1024 next hop for the mapped DestPrefix. 1026 2. The Node receives a PID Response message from a Node that is 1027 not the next hop for the DestPrefix. 1029 The DestPrefix TLV specifies the DestPrefix for which PIDs are to be 1030 released. If a WildCard PID TLV is received, all PIDs associated with 1031 the DestPrefix and the ToP are to be released; otherwise, only the 1032 PID specified in the PID TLV is to be released. 1034 The DestPrefix TLV may contain the Wildcard DestPrefix; In this case, 1035 if the PID Release message contains a none-WildCard PID TLV, then the 1036 PID is to be released for all DestPrefixes to which it is bound. If 1037 there is a WildCard PID TLV in the PID Release message, then the 1038 sending Node is releasing all PID mappings previously learned from 1039 the receiving peer of the ToP in the message. 1041 See Section "QTP Procedures" for more details. 1043 3.5 Summary 1045 3.5.1 Message Summary 1047 The following are the QTP messages defined in this version of the 1048 protocol. 1050 Message Name Type Section Title 1052 Notification 0x0001 "Notification Message" 1053 KeepAlive 0x0101 "KeepAlive Message" 1054 PID Request 0x0201 "PID Request Message" 1055 PID Response 0x0202 "PID Response Message" 1056 PID Release 0x0203 "PID Release Message" 1058 3.5.2 TLV Summary 1060 The following are the TLVs defined in this version of the protocol. 1062 TLV Type Section Title 1064 DestPrefix 0x0100 "DestPrefix TLV" 1065 PID 0x0200 "PID TLV" 1066 ToP 0x0300 "ToP TLV" 1067 Status 0x0400 "Status TLV" 1069 3.5.3 Status Code Summary 1071 The following are the Status Codes defined in this version of the 1072 protocol. 1074 The "E" column is the required setting of the Status Code E-bit; the 1075 "Status Data" column is the value of the 32-bit Status Data field in 1076 the Status Code TLV. 1078 Status Code E Status Data Section Title 1079 Success 0 0x00000000 "Status TLV" 1080 Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." 1081 Bad Protocol Version 1 0x00000002 "Events Signaled by ..." 1082 Bad PDU Length 1 0x00000003 "Events Signaled by ..." 1083 Unknown Message Type 0 0x00000004 "Events Signaled by ..." 1084 Bad Message Length 1 0x00000005 "Events Signaled by ..." 1085 Unknown TLV 0 0x00000006 "Events Signaled by ..." 1086 Bad TLV Length 1 0x00000007 "Events Signaled by ..." 1087 Malformed TLV Value 1 0x00000008 "Events Signaled by ..." 1088 Shutdown 1 0x00000009 "Events Signaled by ..." 1089 Unknown DestPrefix 0 0x0000000A "DestPrefix TLV" 1090 No Route 0 0x0000000B "PID Request Message" 1091 No PID Resources 0 0x0000000C "PID Request Message" 1092 PID Resources/ 0 0x0000000D "PID Request Message" 1093 Available 1094 KeepAlive Timer/ 1 0x0000000E "Events Signaled by ..." 1095 Expired 1096 Unsupported Address/ 0 0x0000000F "DestPrefix TLV" 1097 Family 1098 Internal Error 1 0x00000010 "Events Signaled by ..." 1100 4 QTP Procedure 1102 4.1 Establishment of QTP-Path 1104 4.1.1 The trigger condition of QTP-Path establishing 1106 When the business is running in the virtual network, the data can be 1107 transmitted through QTP-Path. After the management plane determines 1108 establish QTP-Path between two nodes, it carries out the process of 1109 QTP-Path establishing through the control plane. The determination of 1110 QTP-Path establishing can be obtained through the management plane's 1111 gathering business requests and the perception of network status, or 1112 the network administrator manually configures. Once the establishment 1113 determination is made, the control plane needs the parameters of QTP- 1114 Path, i.e. source node, destination node, flow types and so on, after 1115 obtaining those parameters, the control plane will establish and 1116 maintain QTP-Path according to the protocol. 1118 4.1.2 Path establishment process 1120 Path establishment start from the source node, and sends request 1121 message hop by hop. The node receives the message and judges if it 1122 meets the requests, if no, the node sends warning message reversely, 1123 else it continues to send request message to the next node until to 1124 the destination node. The destination node sends reply message 1125 reversely along the path to the source node, the establishment of 1126 QTP-Path is successful. This section describes the establishment 1127 process in detail. 1129 A Node processes a received PID Request message as follows: 1131 1. The Node looks up in the local routing table for the next hop 1132 of DestPrefix. If the node can not find the next hop, it sends 1133 Notification message of "No Route", and the process goes to 8. 1135 2. Check whether the node has established TCP connection with the 1136 next hop, if not, this node initiates a request for 1137 establishing the TCP connection, and after the connection is 1138 done, start KeepAlive timer. If the connection can not be 1139 established, then the node sends Notification message of 1140 "ShutDown", and the process goes to 8. 1142 3. Check whether PIB consists tables of DestPrefix and ToP, and 1143 judges whether the next hop in PIB is the one in routing 1144 tables: 1146 a. If so, insert the PID value of the table to PID Response 1147 Message, and forward the message to the upstream node, then 1148 the process goes to 8. 1150 b. If not,insert the PID value of the table to PID Release,and 1151 forward the message to the next hop, then delete the table. 1153 4. Check whether this node supports ToP traffic forwarding, if 1154 not, forward Notification message of " Internal Error" to the 1155 upstream node, then the process goes to 8. 1157 5. Check whether this node has residual PIDs, if not, forward 1158 Notification message of " No PID Resources" to the upstream 1159 node, then the process goes to 8. 1161 6. Forward the message of PID Request message to the next hop, and 1162 wait to receive the downstream message. 1164 7. The reply message received from the downstream nodes: 1166 a. If the message is PID Response, insert new tables which 1167 consist of DestPrefix, ToP, PID, NextPID, Nexthop etc.to PIB 1168 according to the PID value in reply message. Insert the PID 1169 value locally generated to PID Response Message, and forward 1170 the message to upstream nodes. 1172 b. If the message is Notification, then forward the message to 1173 upstream nodes 1175 8. Over 1177 4.2. Removal of the QTP-Path 1179 4.2.1 The trigger condition of removal process 1181 When the management plane determines to remove QTP-Path between two 1182 nodes, it carries out the removal process of QTP-Path through the 1183 control plane. The determination of QTP-Path removal can be obtained 1184 through the perception of network status and learning, or the network 1185 administrator manually configures. After the removal determination is 1186 made, the management plane gives the source node, destination node 1187 and business types, in this way, the control plane can carry out the 1188 removal process successfully. 1190 4.2.2 QTP-Path removal process 1192 The removal of QTP-Path starts from the source node and sends removal 1193 message along the path. 1195 The procedure in which node processes PID Release message is as 1196 follows: 1198 1. If the message comes from upstream nodes, forward it to 1199 downstream nodes; if it comes from downstream nodes; forward it 1200 to upstream nodes. 1202 2. If the value of PID equals to the value of WildCard, delete the 1203 tables in PIB which meets DestPrefix and ToP, else delete the 1204 tables in PIB which meets DestPrefix, ToP and PID 1206 4.3. QTP-Path adjustment process 1208 4.3.1 The trigger condition of QTP-Path adjustment 1210 When the management plane determines to adjust QTP-Path between two 1211 nodes, it carries out the adjustment process of QTP-Path through the 1212 control plane. The determination of QTP-Path adjustment can be 1213 obtained through the management plane's gathering business requests 1214 and the perception of network status, or the network administrator 1215 manually configures. Under the two conditions below, the management 1216 plane will adjust QTP-Path: 1218 1. A link of QTP-Path fails. 1220 2. A link or a section of QTP-Path congests, resulting in that 1221 data transmission can not meet business needs. Once the 1222 adjustment determination is made, the control plane needs the 1223 parameters of QTP-Path, e.g. source node, destination node, 1224 business types etc., after obtaining those parameters, the 1225 control plane will adjust QTP-Path according to the protocol. 1227 4.3.2 QTP-Path Adjustment Process 1229 When the management plane determines to adjust QTP-Path between two 1230 nodes, it sends QTP-Path establishment message to source nodes, then 1231 the source node sends PID Request message to downstream nodes. The 1232 adjustment process is similar to the establishment process. Because 1233 the adjustment of QTP-Path is based on the link availability or QoS 1234 performance, the adjustment process depends on the routing protocol 1235 on the node. 1237 5 Security Considerations 1239 TBA. 1241 6 IANA Considerations 1243 This memo includes no request to IANA. 1245 7 References 1247 7.1 Normative References 1249 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1250 Requirement Levels", BCP 14, RFC 2119, March 1997. 1252 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1253 Guidelines for DiffServ Service Classes", RFC 4594, August 1254 2006. 1256 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1257 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1258 Encoding", RFC 3032, January 2001. 1260 [I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A., 1261 Venkataramaiah, N., Wang, Y., Duda, K., Ganga, I., Lin, 1262 G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: 1263 Network Virtualization using Generic Routing 1264 Encapsulation", draft-sridharan-virtualization-nvgre-02 1265 (work in progress), February 2013. 1267 7.2 Informative References 1269 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1270 RFC 3514, April 1 2003. 1272 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1273 Acronyms", RFC 5513, April 1 2009. 1275 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1276 2009. 1278 Authors' Addresses 1280 Julong Lan 1281 National Digital Switching System Engineering and Technological 1282 Research Center 1283 NDSC, No.7 , Jianxue Street,Jinshui District 1284 Zhengzhou, 450002 1285 P.R.China 1287 Phone: +86-371-8163-2988 1288 Email: ndscljl@163.com 1289 URI: http://www.ndsc.com.cn/ 1291 Dongnian Cheng 1292 National Digital Switching System Engineering and Technological 1293 Research Center 1294 NDSC, No.7 , Jianxue Street,Jinshui District 1295 Zhengzhou, 450002 1296 P.R.China 1298 Phone: +86-371-8163-2743 1299 Email: cdn@mail.ndsc.com.cn 1300 URI: http://www.ndsc.com.cn/ 1302 Yuxiang Hu 1303 National Digital Switching System Engineering and Technological 1304 Research Center 1305 NDSC, No.7 , Jianxue Street,Jinshui District 1306 Zhengzhou, 450002 1307 P.R.China 1309 Phone: +86-371-8163-2737 1310 Email: chxachxa@126.com 1312 Guozhen Cheng 1313 National Digital Switching System Engineering and Technological 1314 Research Center 1315 NDSC, No.7 , Jianxue Street,Jinshui District 1316 Zhengzhou, 450002 1317 P.R.China 1319 Phone: +86-371-8163-2725 1320 Email: chengguozhen1986@163.com 1322 Tong Duan 1323 National Digital Switching System Engineering and Technological 1324 Research Center 1325 NDSC, No.7 , Jianxue Street,Jinshui District 1326 Zhengzhou, 450002 1327 P.R.China 1329 Phone: +86-371-8163-2846 1330 Email: duantong21@126.com