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