idnits 2.17.1 draft-lan-nvo3-qtp-05.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 12, 2017) is 2564 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 1250, but no explicit reference was found in the text == Unused Reference: 'RFC4594' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 1257, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1276, 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 12, 2017 Y. Hu 4 G. Cheng 5 Z. Wang 6 L. Sun 7 National Digital Switching System Engineering and Technological 8 Research Center, P.R.China 9 April 12, 2017 11 QoS-level aware Transmission Protocol (QTP) for virtual networks 12 draft-lan-nvo3-qtp-05 14 Abstract 16 This document provides a QoS-level aware Transmission Protocol (QTP) 17 for virtual networks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Motivation and background . . . . . . . . . . . . . . . . . 4 59 1.2 QTP-path . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3 QTP Overview . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.5 Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5 63 2 QTP Data Encapsulation Specification . . . . . . . . . . . . . 5 64 2.1 QTP Header Specification . . . . . . . . . . . . . . . . . 5 65 2.2 QTP Data Encapsulation . . . . . . . . . . . . . . . . . . 6 66 3 QTP Message Specification . . . . . . . . . . . . . . . . . . . 7 67 3.1 Destination Prefix and Node Identifiers . . . . . . . . . . 8 68 3.1.1 Destination Prefix (DestPrefix) . . . . . . . . . . . . 8 69 3.1.2 Node Identifiers . . . . . . . . . . . . . . . . . . . . 8 70 3.2 QTP PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.3 TLV Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3.1 DestPrefix TLV . . . . . . . . . . . . . . . . . . . . . 11 73 3.3.2 PID TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.3.3 ToP TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.3.4 Status TLV . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.4 QTP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 77 3.4.1 Notification Message . . . . . . . . . . . . . . . . . . 16 78 3.4.1.1 Notification Message Procedures . . . . . . . . . . 17 79 3.4.1.2 Events Signaled by Notification Messages . . . . . . 17 80 3.4.2 KeepAlive Message . . . . . . . . . . . . . . . . . . . 19 81 3.4.2.1 KeepAlive Message Procedures . . . . . . . . . . . . 19 82 3.4.3 PID Request Message . . . . . . . . . . . . . . . . . . 19 83 3.4.3.1 PID Request Message Procedures . . . . . . . . . . . 20 84 3.4.4 PID Response Message . . . . . . . . . . . . . . . . . . 21 85 3.4.4.1 PID Response Message Procedures . . . . . . . . . . 22 86 3.4.5 PID Release Message . . . . . . . . . . . . . . . . . . 22 87 3.4.5.1 PID Release Message Procedures . . . . . . . . . . . 23 88 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 3.5.1 Message Summary . . . . . . . . . . . . . . . . . . . . 24 90 3.5.2 TLV Summary . . . . . . . . . . . . . . . . . . . . . . 24 91 3.5.3 Status Code Summary . . . . . . . . . . . . . . . . . . 24 92 4 QTP Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 4.1 Establishment of QTP-Path . . . . . . . . . . . . . . . . . 25 94 4.1.1 The trigger condition of QTP-Path establishing . . . . . 25 95 4.1.2 Path establishment process . . . . . . . . . . . . . . . 25 96 4.2. Removal of the QTP-Path . . . . . . . . . . . . . . . . . . 27 97 4.2.1 The trigger condition of removal process . . . . . . . . 27 98 4.2.2 QTP-Path removal process . . . . . . . . . . . . . . . . 27 99 4.3. QTP-Path adjustment process . . . . . . . . . . . . . . . . 27 100 4.3.1 The trigger condition of QTP-Path adjustment . . . . . . 27 101 4.3.2 QTP-Path Adjustment Process . . . . . . . . . . . . . . 28 102 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 28 103 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 104 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 7.1 Normative References . . . . . . . . . . . . . . . . . . . 28 106 7.2 Informative References . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 109 1 Introduction 111 1.1 Motivation and background 113 Virtual network has been designed to implement all types of network, 114 to achieve scalability in today's Internet, for example, multi- 115 tenants sharing network in data center network. This document 116 provides a QoS-level aware Transmission Protocol (QTP) for virtual 117 networks. Since virtual network transmits data in the form of "best 118 effort" under today's connectionless network, its performance cannot 119 be guaranteed. In addition, due to the elasticity of network traffic, 120 virtual networks sharing the same physical network cannot achieve 121 minimum resource guarantee and fairness under network congestion. QTP 122 constructs various data transmission tunnels, namely, QTP-path, for 123 different virtual networks that have special requests. We embed a 124 field named QTP-path identifier (PID) in QTP header, and explicitly 125 contains QoS level to indicate the resource level sharing when data 126 transmission. 128 1.2 QTP-path 130 The applications on the virtual network always originate requirements 131 that have identical path and performance. Therefore, QTP aggregates 132 these requirements, and constructs one data transmission tunnel to 133 maximize network throughput. The tunnel, we say, QTP-path is labeled 134 by a QoS level according with the requests in the protocol header. 136 1.3 QTP Overview 138 We assume that all the network nodes can handle global knowledge 139 about network loads and application requests. If there are several 140 pairs in network originate requests for identical QoS level and have 141 common in path, then the management plane decides to establish a QTP- 142 path in the common part of the path. Firstly, the starting node 143 assign a PID to the path, and send QTP-path establish request. Then 144 the relative nodes on the path update their path information base 145 (PIB) which storage the PIDs of QTP-paths across it. Finally, when 146 the QTP-path has been established, the data transmitted over it can 147 be transfer based on PIB matching PID in PDUs, and realize QoS level 148 guarantee. 150 1.4 Terminology 152 QTP-path the tunnel established for the same requests by 153 QTP can be used to transmission data. 154 QTP-path identifier represented as a 32-bit number in a 4 octet field 155 Node Identifier a four octet quantity used to identify an 156 QTP Node. 158 1.5 Acronyms and Abbreviations 159 PDU protocol data unit 160 TTL Time to live 161 ToP Type of QTP-path 162 PID QTP-path Identifier 163 TTL Time to live 164 TLV Type-Length-Value 165 PIB QTP-path information base 167 2 QTP Data Encapsulation Specification 169 2.1 QTP Header Specification 171 Each packet over QTP-path MUST have a QTP header. The QTP header is 172 represented by 4 octets. This is shown in Figure 1. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | ToP | PID | TTL | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ToP: Type of QTP-path, 6 bits 181 PID: QTP-path Identifier, 18 bits 182 TTL: Time to live, 8 bits 184 Figure 1 186 The QTP header appears AFTER the data link layer header, but BEFORE 187 any network layer header. Each QTP header is broken down into the 188 following fields: 190 o Type of QTP-path (ToP) 192 This six-bit field is used to identify the type of QTP-path. 193 Each type of QTP-path SHALL carry only one class of traffic. RFC 194 4594 has defined twelve different classes of traffic, namely, 195 network control, telephony, signaling, multimedia conferencing, 196 real-time interactive, multimedia streaming, broadcast video, 197 low-latency data, OAM, high-throughput data, standard, and low- 198 priority data. End-to-end quantitative performance requirements 199 may be obtained from ITU-T Recommendations Y.1541 and Y.1540. It 200 is RECOMMENDED that the value of ToP be the same with DSCP 201 value. 203 o QTP-path Identifier (PID) 205 This 18-bit field carries the actual value of the QTP-Path 206 identifier. When a QTP-path packet is received, the PID value is 207 looked up to obtain the next hop to which the packet is to be 208 forwarded. Before forwarding, the PID may be replaced with 209 another, or be popped off with the whole QTP-path header. 211 o Time to live (TTL) 213 This eight-bit field is used to encode a time-to-live value. The 214 processing of this field is the same with that of MPLS TTL field 215 in RFC 3032. 217 Different types of QTP-paths MUST have different behaviors on QoS 218 guarantee and resource allocation to achieve their required traffic 219 characteristics. 221 2.2 QTP Data Encapsulation 223 The packet format for QTP-path is shown in Figure 2. 225 QTP header encapsulation is used to realize a QTP-path, and the 226 header by definition in section 2.1 contains a ToP, a PID, and a TTL. 228 NVGRE encapsulation is used to realize an overlay virtual network. 229 The virtual network identifier is carried as the 24-bit VSID in the 230 NVGRE header. 232 0 1 2 3 233 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 234 Outer Ethernet Header: 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Outer Destination MAC Address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Outer Destination MAC Address | Outer Source MAC Address | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Outer Source MAC Address | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Ethertype = 0x01FF | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Outer QTP Header: 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | ToP | PID | TTL | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Outer IPv4 Header: 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |Version| IHL |Type of Service| Total Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Identification |Flags| Fragment Offset | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Time to Live | Protocol=0x2F | Header Checksum | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Outer Source IPv4 Address | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Outer Destination IPv4 Address | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 NVGRE Encapsulation: 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 | NVGRE Encapsulation | 264 | (include NVGRE Header, Original Inner Ethernet Frame) | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Frame Check Sequence: 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2 274 The QTP data encapsulation includes the outer Ethernet header, the 275 QTP-path header, the outer IPv4 header, and the NVGRE encapsulation: 277 o Outer Ethernet header: The source MAC address in the outer frame 278 is set to the MAC address associated with the NVGRE endpoint. The 279 destination MAC address is set to the MAC address of the nexthop 280 IP address for the destination NVE. The EtherType field is set to 281 0x01FF which is reserved for experimental use. 283 o QTP header: The ToP is used to identify the type of QTP-path, 284 the PID is used to identify the QTP-path, and the TTL is used to 285 record the time to live for the QTP-path. 287 o Outer IPv4 header: IPv4 is used as the delivery protocol for 288 NVGRE. The protocol field in the IPv4 header is set to 0x2F. The 289 IP address in the outer frame is referred to as the Provider 290 Address (PA). 292 o NVGRE encapsulation: It includes NVGRE header, and original 293 inner Ethernet frame. The VSID in NVGRE header can be used to 294 identify the different virtual networks. The original inner 295 Ethernet frame comprises of an inner Ethernet header followed by 296 the inner IP header, followed by the IP payload. 298 3 QTP Message Specification 300 QTP message exchanges are accomplished by sending QTP protocol data 301 units (PDUs) over TCP connections. Each QTP PDU can carry one or more 302 QTP messages. Note that the messages in a QTP PDU need not be related 303 to one another. For example, a single PDU could carry a PID Request 304 message, another message for PID Responding message, and a third 305 Notification message that signals some event. 307 3.1 Destination Prefix and Node Identifiers 309 3.1.1 Destination Prefix (DestPrefix) 311 A DestPrefix specification for each QTP-Path is provided to precisely 312 specify which packets may be mapped to each QTP-Path. The DestPrefix 313 identifies the set of IP packets that may be mapped to that QTP-Path. 315 This specification defines DestPrefix as an address prefix of any 316 length from 0 to a full address, inclusive. We give the rules used 317 for mapping packets to QTP-Path that have been set up using a 318 DestPrefix in the remainder of this section. 320 We say that a particular address matches a particular address prefix 321 if and only if that address begins with that prefix. We also say that 322 a particular packet matches a particular QTP-Path if and only if the 323 packet's destination address matches the DestPrefix of that QTP-Path. 325 The following rules describe the procedure for mapping a particular 326 packet to a particular QTP-Path. 328 - If a packet matches exactly one QTP-Path, the packet is mapped 329 to that QTP-Path. 331 - If a packet matches multiple QTP-Paths, it is mapped to the 332 QTP-Path whose matching DestPrefix is the longest. 334 - If it is known that a packet must traverse a particular egress 335 router, and there is a QTP-Path with a DestPrefix that is a /32 336 address of that router, then the packet is mapped to that QTP- 337 Path. 339 3.1.2 Node Identifiers 341 A Node Identifier is a four octet quantity used to identify a QTP 342 Node. The Node Identifier must be a globally unique value, such as a 343 32-bit router Id assigned to the QTP Node. 345 3.2 QTP PDU 347 Each QTP PDU consists of a QTP header and one or more QTP messages. 348 The QTP header is: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Version | PDU Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Node Identifier | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Version 359 Two octet unsigned integer containing the version number of the 360 protocol. This version of the specification specifies QTP 361 protocol version 1. 363 PDU Length 364 Two octet integer specifying the total length of this PDU in 365 octets, excluding the Version and PDU Length fields. 367 Node Identifier 368 Four octet field that uniquely identifies the node and MUST be a 369 globally unique value. It SHOULD be a 32-bit router Id assigned to 370 the Node . 372 3.3 TLV Encoding 374 QTP uses a Type-Length-Value (TLV) encoding scheme to encode the 375 information carried in QTP messages. 377 A QTP TLV is encoded as a 2 octet field that uses 15 bits to specify 378 a Type and 1 bits to specify behavior when a Node doesn't recognize 379 the Type, followed by a 2 octet Length field, followed by a variable 380 length Value field. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |U| Type | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | Value | 389 ~ ~ 390 | | 391 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 U-bit 396 Unknown TLV bit. When an unknown TLV is recieved, if U is 397 clear(=0), a notification MUST be returned to the message 398 originator and the entire message MUST be ignored; if U is set 399 (=1), the unknown TLV MUST be silently ignored and the rest of the 400 message processed as if the unknown TLV did not exist. 402 Type 403 Encodes how the Value field is to be interpreted. 405 Length 406 Specifies the length of the Value field in octets. 408 Value 409 Octet string of Length octets that encodes information to be 410 interpreted as specified by the Type field. 412 Note that there is no alignment requirement for the first octet of a 413 TLV. TLVs may be nested, that is the Value field itself may contain 414 TLV encodings. 416 The TLV encoding scheme is very general. In principle, everything in 417 a QTP PDU could be encoded as a TLV. Note that the TLV scheme is not 418 used to its full generality in this specification. 420 The specification assigns type values for related TLVs, such as the 421 PID TLVs, from a contiguous block in the 16-bit TLV type number 422 space. Section "TLV Summary" lists the TLVs defined in this version 423 of the protocol. 425 In this section, the TLV encodings for some commonly used parameters 426 are specified. 428 3.3.1 DestPrefix TLV 430 PIDs are bound to DestPrefixes. A DestPrefix TLV encodes a list of 431 one or more DestPrefix Items. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |0| DestPrefix (0x0100) | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | DestPrefix Item 1 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 ~ ~ 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | DestPrefix Item n | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 DestPrefix Item 1 to DestPrefix Item n 448 The DestPrefix Item encoding depends on the type of DestPrefix. 450 A DestPrefix value is encoded as a 1 octet field that specifies 451 the element type, and a variable length field that is the type- 452 dependent DestPrefix value. 454 The DestPrefix value encoding is: 456 DestPrefix Type Value type name 458 Wildcard 0x01 No value; i.e., 0 value octets; 459 See below. 461 Prefix 0x02 See below. 463 Wildcard DestPrefix 464 To be used only in the PID Release messages indicating that the 465 release is to be applied to all DestPrefixes associated with 466 the PID within the following PID TLV. Must be the only 467 DestPrefix Item in the DestPrefix TLV. 469 DestPrefix value encoding: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Prefix (2) | Address Family | PreLen | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Prefix | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Address Family 480 Two octet quantity containing a value from ADDRESS FAMILY 481 NUMBERS in [ASSIGNED_AF] that encodes the address family for 482 the address prefix in the Prefix field. 484 PreLen 485 One octet unsigned integer containing the length in bits of the 486 address prefix that follows. A length of zero indicates a 487 prefix that matches all addresses (the default destination), in 488 this case, the Prefix itself is zero octets. 490 Prefix 491 An address prefix encoded according to the Address Family 492 field, whose length was specified in bits in the PreLen field, 493 padded to a byte boundary. 495 When decoding a DestPrefix TLV, if a Node encounters a DestPrefix 496 with an Address Family it does not support, it SHOULD stop decoding 497 the DestPrefix TLV, abort processing the message containing the TLV, 498 and send an "Unsupported Address Family" Notification message to its 499 QTP peer. If a Node encounters a DestPrefix type it cannot decode, it 500 SHOULD stop decoding the DestPrefix TLV, abort processing the message 501 containing the TLV, and send an "Unknown DestPrefix " Notification 502 message to its QTP peer. 504 3.3.2 PID TLV 506 A PID TLV are used to encode a PID. The encoding for PID TLV is: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |0| PID (0x0200) | Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | PID | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 PID 517 This is a 18-bit PID value represented as a 18-bit number in a 4 518 octet field as follows: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | PID | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 3.3.3 ToP TLV 528 When establishing a QTP-Path, a ToP TLV is used to specify type of 529 QTP-Path and the QoS guarantee feature of the QTP. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |0| ToP (0x0300) | Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | ToP | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 ToP 540 This is a 6-bit ToP value represented as a 6-bit number in a 4 541 octet field as follows: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ToP | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 A ToP TLV with Length 0 is a WildCard ToP. 551 3.3.4 Status TLV 553 Status TLVs are carried in Notification messages to specify events 554 being signaled. The encoding for the Status TLV is: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |U| Status (0x0400) | Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Status Code | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Message ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Message Type | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 U-bit 568 SHOULD be 0 when the Status TLV is sent in a Notification message. 569 SHOULD be 1 when the Status TLV is sent in some other message. 571 Status Code 572 32-bit unsigned integer encoding the event being signaled. The 573 structure of a Status Code is: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |E|F| Status Data | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 E-bit 582 Error bit. If set (=1), this is a fatal Error Notification. If 583 clear (=0), this is an Advisory Notification. 585 F-bit 586 Forward bit. If set (=1), the notification SHOULD be forwarded 587 to the Node for the next-hop or previous-hop of the QTP-Path. 588 If clear (=0), the notification SHOULD NOT be forwarded. 590 Status Data 591 30-bit unsigned integer that specifies the status information. 593 Status Codes are 32-bit unsigned integers with the above encoding. 594 The Status Codes are defined in this specification. 596 A Status Code of 0 signals success. 598 Message ID 599 If non-zero, 32-bit value that identifies the peer message to 600 which the Status TLV refers. If zero, no specific peer message is 601 being identified. 603 Message Type 604 If non-zero, the type of the peer message to which the Status TLV 605 refers. If zero, the Status TLV does not refer to any specific 606 message type. 608 3.4 QTP messages 610 The messages for the QTP procedures are described in following 611 sections. 613 The QTP procedures are complex and are difficult to describe fully, 614 coherently, and unambiguously as a collection of separate message and 615 TLV specifications. Section "QTP Procedures" describes the QTP 616 procedures in terms of QTP-Path events that may occur at a Node and 617 how the Node must respond. 619 All QTP messages have the following format: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |U| Message Type | Message Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Message ID | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | 629 + + 630 | Parameters | 631 + + 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 U-bit 636 Unknown message bit. When an unknown message is received, if U is 637 clear (=0), a notification is returned to the message originator; 638 if U is set (=1), the unknown message is silently ignored. The 639 sections following that define messages specify a value for the U- 640 bit. 642 Message Type 643 Identifies the type of message. 645 Message Length 646 Specifies the cumulative length in octets of the Message ID and 647 Parameters. 649 Message ID 650 32-bit value used to identify this message. Used by the sending 651 Node to facilitate identifying Notification messages that may 652 apply to this message. A Node sending a Notification message in 653 response to this message SHOULD include this Message ID in the 654 Status TLV carried by the Notification message; see Section 655 "Notification Message". 657 Parameters 658 Variable length set of required message parameters. Some messages 659 have no required parameters. 661 For messages that have required parameters, the required 662 parameters MUST appear in the order specified by the individual 663 message specifications in the sections that follow. Note that 664 there is no alignment requirement for the first octet of a QTP 665 message and that there is no padding at the end of a message; that 666 is, parameters can end at odd-byte boundaries. 668 The following message types are defined in this specification: 670 Message Name Section Title 672 Notification "Notification Message" 673 KeepAlive "KeepAlive Message" 674 PID Request "PID Request Message" 675 PID Response "PID Response Message" 676 PID Release "PID Release Message" 678 The sections that follow specify the encodings and procedures for 679 these messages. 681 3.4.1 Notification Message 683 A Node sends a Notification message to inform its QTP peer of a 684 significant event. A Notification message signals a fatal error or 685 provides advisory information such as the outcome of processing a QTP 686 message. 688 The encoding for the Notification message is: 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |0| Notification (0x0001) | Message Length | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Message ID | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Status (TLV) | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | ToP (TLV) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Message ID 703 32-bit value used to identify this message. 705 Status TLV 706 Indicates the event being signaled. The encoding for the Status 707 TLV is specified in Section "Status TLV". 709 ToP TLV 710 Indicates the ToP associate with the event being signaled. The 711 encoding for the ToP TLV is specified in Section "ToP TLV". 713 3.4.1.1 Notification Message Procedures 715 If a Node encounters a condition requiring it to notify its peer with 716 advisory or error information, it sends the peer a Notification 717 message containing a Status TLV that encodes the information about 718 the condition and a ToP TLV indicating the ToP associate the 719 condition. 721 If a fatal error occurs, the Status Code carried in the Notification 722 will indicate that. In this case, after sending the Notification 723 message the Node SHOULD discard all PID-DestPrefix bindings learned 724 from the peer. 726 3.4.1.2 Events Signaled by Notification Messages 728 For descriptive purpose, it is useful to classify events signaled by 729 Notification messages into the following categories. Note that the 730 ToP field is fill with a WildCard ToP TLV if not mentioned in the 731 following circumstances. 733 3.4.1.2.1 Malformed PDU or Message 735 A QTP PDU received on a TCP connection is malformed if: 737 - The Node Identifier in the PDU header is unknown to the 738 receiver, or it is known but is not the QTP Identifier 739 associated by the receiver with the QTP peer. This is a fatal 740 error signaled by the Bad QTP Identifier Status Code. 742 - The QTP protocol version is not supported by the receiver. This 743 is a fatal error signaled by the Bad Protocol Version Status 744 Code. 746 - The PDU Length field is too small (< 12) or too large (>maximum 747 PDU length). This is a fatal error signaled by the Bad PDU 748 Length Status Code. 750 A QTP message is malformed if: 752 - The Message Type is unknown. 754 If the Message Type is < 0x8000 (high order bit = 0), it is an 755 error signaled by the Unknown Message Type Status Code. 757 If the Message Type is >= 0x8000 (high order bit = 1), it is 758 silently discarded. 760 - The Message Length is too large indicating that the message 761 extends beyond the end of the containing QTP PDU. This is a 762 fatal error signaled by the Bad Message Length Status Code. 764 - The Message Length is too small, that is, smaller than the 765 smallest possible value component. This is a fatal error 766 signaled by the Bad Message Length Status Code. 768 3.4.1.2.2 Unknown or Malformed TLV 770 A TLV contained in a QTP message received on a TCP connection is 771 malformed if: 773 - The TLV Length is too large indicating that the TLV extends 774 beyond the end of the containing message. This is a fatal error 775 signaled by the Bad TLV Length Status Code. 777 - The TLV type is unknown. 779 If the TLV type is < 0x8000 (high order bit = 0), it is an 780 error signaled by the Unknown TLV Status Code. 782 If the TLV type is >= 0x8000 (high order bit = 1), the TLV is 783 silently dropped. 785 - The TLV Value is malformed. This occurs when the receiver 786 handles the TLV but cannot decode the TLV Value. It is a fatal 787 error signaled by the Malformed TLV Value Status Code. 789 3.4.1.2.3 Session KeepAlive Timer Expiration 791 This is a fatal error signaled by the KeepAlive Timer Expired Status 792 Code. 794 3.4.1.2.4 Unilateral Connection Shutdown 796 This is a fatal event signaled by the Shutdown Status Code. 798 3.4.1.2.5 Events Resulting from Other Messages 800 Messages may result in events that must be signaled to QTP peers via 801 Notification messages. These events and the Status Codes used in the 802 Notification messages to signal them are described in the sections 803 that describe these messages. 805 3.4.1.2.6 Internal Errors 807 A QTP implementation may detect problem conditions specific to its 808 implementation. When such a condition prevents an implementation from 809 interacting correctly with a peer, the implementation should, when 810 capable of doing so, use the Internal Error Status Code to signal the 811 peer. This is a fatal error. 813 3.4.1.2.7 Miscellaneous Events 815 These are events that fall into none of the categories above. There 816 are no miscellaneous events defined in this version of the protocol. 818 3.4.2 KeepAlive Message 820 A Node sends KeepAlive messages as part of a mechanism that monitors 821 the integrity of the TCP connection with another peer. 823 The encoding for the KeepAlive message is: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 |0| KeepAlive (0x0101) | Message Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Message ID | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Message ID 834 32-bit value used to identify this message. 836 3.4.2.1 KeepAlive Message Procedures 838 The KeepAlive Timer resets a KeepAlive Timer every time a QTP PDU is 839 received. The KeepAlive message is provided to allow reset of the 840 KeepAlive Timer in circumstances where a Node has no other 841 information to communicate to a peer. 843 A Node MUST arrange that its peer receive a QTP message of any type 844 from it at least every KeepAlive Time period. But a KeepAlive message 845 MUST be sent in circumstances where no other QTP protocol messages 846 have been sent within the period. 848 3.4.3 PID Request Message 850 A Node sends the PID Request message to a peer to request a binding 851 (mapping) for a DestPrefix. The encoding for the PID Request message 852 is: 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |0| PID Request (0x0201) | Message Length | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Message ID | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | DestPrefix TLV | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | ToP TLV | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Message ID 867 32-bit value used to identify this message. 869 DestPrefix TLV 870 The DestPrefix for which a PID is being requested. See Section 871 "DestPrefix TLV" for encoding. 873 ToP TLV 874 The ToP of the QTP being established. See Section "ToP TLV" for 875 encoding. 877 3.4.3.1 PID Request Message Procedures 879 The Request message is used by an upstream Node to request that the 880 downstream Node assign and advertise a PID for a DestPrefix of a 881 specific ToP. 883 A Node may transmit a Request message under any of the following 884 conditions: 886 1. The Node is informed by the management modular (manually or 887 automatically) to establish a QTP for the given DestPrefix and 888 the given ToP while it has recognized the DestPrefix via the 889 forwarding table with the next hop being a QTP peer and the 890 Node not already having a mapping from the next hop for the 891 given DestPrefix. 893 2. The next hop to the DestPrefix changes, and the Node doesn't 894 already have a mapping from that next hop for the given 895 DestPrefix. 897 Note that if the Node already has a pending PID Request message 898 for the new next hop, it SHOULD NOT issue an additional PID 899 Request in response to the next hop change. 901 3. The Node receives a PID Request for a DestPrefix from an 902 upstream peer, the DestPrefix next hop is a QTP peer, and the 903 Node doesn't already have a mapping from the next hop. 905 The receiving Node SHOULD respond to a PID Request message with a PID 906 Response message with a requested PID or with an error status 907 indicating why it cannot satisfy the request. 909 When the DestPrefix for which a PID is requested is a DestPrefix, the 910 receiving Node uses its routing table to determine its response. 911 Unless its routing table includes an entry that exactly matches the 912 requested Prefix, the Node MUST respond with a No Route Notification 913 message. 915 This version of the protocol defines the following Status Codes for 916 the Notification message that signals a request cannot be satisfied: 918 No Route 919 The DestPrefix for which a PID was requested includes a 920 DestPrefix for which the Node does not have a route. 922 No PID Resources 923 The Node cannot provide a PID because of resource limitations. 924 When resources become available, the Node MUST notify the 925 requesting Node by sending a Notification message with the PID 926 Resources Available Status Code. 928 See Section "QTP Procedures" for more details. 930 3.4.4 PID Response Message 932 A Node sends a PID Response message to a peer to advertise 933 DestPrefix-PID bindings to the peer. 935 The encoding for the PID Mapping message is: 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 |0| PID Mapping (0x0202) | Message Length | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Message ID | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | DestPrefix TLV | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | ToP TLV | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | PID TLV | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Message ID 952 32-bit value used to identify this message. 954 DestPrefix TLV 955 Specifies the DestPrefix of the DestPrefix-PID mapping being 956 advertised. See Section " DestPrefix TLVs" for encoding. 958 ToP TLV 959 Specifies the ToP of the DestPrefix-PID mapping being advertised. 960 See Section " ToP TLVs" for encoding. 962 PID TLV 963 Specifies the PID component of the DestPrefix-PID mapping. See 964 Section "PID TLV" for encoding. 966 3.4.4.1 PID Response Message Procedures 968 The PID Response message is used by a Node to distribute a PID for a 969 DestPrefix to a QTP peer. 971 A Node is responsible for the consistency of the PID mappings it has 972 distributed and that its peers have these mappings. 974 A Node receiving a PID Response message from a downstream Node for a 975 DestPrefix SHOULD NOT use the PID for forwarding unless its routing 976 table contains an entry that exactly matches the DestPrefix. 978 See Section "QTP Procedures" for more details. 980 3.4.5 PID Release Message 982 An Node sends a PID Release message to an LDP peer to signal the peer 983 that the Node no longer needs specific DestPrefix-PID mappings 984 previously requested of and/or advertised by the peer. 986 The encoding for the PID Release Message is: 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 |0| PID Release (0x0203) | Message Length | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Message ID | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | DestPrefix TLV | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | ToP TLV | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | PID TLV | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Message ID 1003 32-bit value used to identify this message. 1005 DestPrefix TLV 1006 Identifies the DestPrefix for which the DestPrefix-PID mapping is 1007 being released. 1009 ToP TLV 1010 Identifies the ToP for which the DestPrefix-PID mapping is being 1011 released. 1013 PID TLV 1014 The PID being released (see procedures below). 1016 3.4.5.1 PID Release Message Procedures 1018 A Node transmits a PID Release message to a peer when it no longer 1019 needs a PID previously received from or requested of that peer. 1021 A Node MUST transmit a PID Release message under any of the following 1022 conditions: 1024 1. The Node that sent the PID Response message is no longer the 1025 next hop for the mapped DestPrefix. 1027 2. The Node receives a PID Response message from a Node that is 1028 not the next hop for the DestPrefix. 1030 The DestPrefix TLV specifies the DestPrefix for which PIDs are to be 1031 released. If a WildCard PID TLV is received, all PIDs associated with 1032 the DestPrefix and the ToP are to be released; otherwise, only the 1033 PID specified in the PID TLV is to be released. 1035 The DestPrefix TLV may contain the Wildcard DestPrefix; In this case, 1036 if the PID Release message contains a none-WildCard PID TLV, then the 1037 PID is to be released for all DestPrefixes to which it is bound. If 1038 there is a WildCard PID TLV in the PID Release message, then the 1039 sending Node is releasing all PID mappings previously learned from 1040 the receiving peer of the ToP in the message. 1042 See Section "QTP Procedures" for more details. 1044 3.5 Summary 1046 3.5.1 Message Summary 1048 The following are the QTP messages defined in this version of the 1049 protocol. 1051 Message Name Type Section Title 1053 Notification 0x0001 "Notification Message" 1054 KeepAlive 0x0101 "KeepAlive Message" 1055 PID Request 0x0201 "PID Request Message" 1056 PID Response 0x0202 "PID Response Message" 1057 PID Release 0x0203 "PID Release Message" 1059 3.5.2 TLV Summary 1061 The following are the TLVs defined in this version of the protocol. 1063 TLV Type Section Title 1065 DestPrefix 0x0100 "DestPrefix TLV" 1066 PID 0x0200 "PID TLV" 1067 ToP 0x0300 "ToP TLV" 1068 Status 0x0400 "Status TLV" 1070 3.5.3 Status Code Summary 1072 The following are the Status Codes defined in this version of the 1073 protocol. 1075 The "E" column is the required setting of the Status Code E-bit; the 1076 "Status Data" column is the value of the 32-bit Status Data field in 1077 the Status Code TLV. 1079 Status Code E Status Data Section Title 1080 Success 0 0x00000000 "Status TLV" 1081 Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." 1082 Bad Protocol Version 1 0x00000002 "Events Signaled by ..." 1083 Bad PDU Length 1 0x00000003 "Events Signaled by ..." 1084 Unknown Message Type 0 0x00000004 "Events Signaled by ..." 1085 Bad Message Length 1 0x00000005 "Events Signaled by ..." 1086 Unknown TLV 0 0x00000006 "Events Signaled by ..." 1087 Bad TLV Length 1 0x00000007 "Events Signaled by ..." 1088 Malformed TLV Value 1 0x00000008 "Events Signaled by ..." 1089 Shutdown 1 0x00000009 "Events Signaled by ..." 1090 Unknown DestPrefix 0 0x0000000A "DestPrefix TLV" 1091 No Route 0 0x0000000B "PID Request Message" 1092 No PID Resources 0 0x0000000C "PID Request Message" 1093 PID Resources/ 0 0x0000000D "PID Request Message" 1094 Available 1095 KeepAlive Timer/ 1 0x0000000E "Events Signaled by ..." 1096 Expired 1097 Unsupported Address/ 0 0x0000000F "DestPrefix TLV" 1098 Family 1099 Internal Error 1 0x00000010 "Events Signaled by ..." 1101 4 QTP Procedure 1103 4.1 Establishment of QTP-Path 1105 4.1.1 The trigger condition of QTP-Path establishing 1107 When the business is running in the virtual network, the data can be 1108 transmitted through QTP-Path. After the management plane determines 1109 establish QTP-Path between two nodes, it carries out the process of 1110 QTP-Path establishing through the control plane. The determination of 1111 QTP-Path establishing can be obtained through the management plane's 1112 gathering business requests and the perception of network status, or 1113 the network administrator manually configures. Once the establishment 1114 determination is made, the control plane needs the parameters of QTP- 1115 Path, i.e. source node, destination node, flow types and so on, after 1116 obtaining those parameters, the control plane will establish and 1117 maintain QTP-Path according to the protocol. 1119 4.1.2 Path establishment process 1121 Path establishment start from the source node, and sends request 1122 message hop by hop. The node receives the message and judges if it 1123 meets the requests, if no, the node sends warning message reversely, 1124 else it continues to send request message to the next node until to 1125 the destination node. The destination node sends reply message 1126 reversely along the path to the source node, the establishment of 1127 QTP-Path is successful. This section describes the establishment 1128 process in detail. 1130 A Node processes a received PID Request message as follows: 1132 1. The Node looks up in the local routing table for the next hop 1133 of DestPrefix. If the node can not find the next hop, it sends 1134 Notification message of "No Route", and the process goes to 8. 1136 2. Check whether the node has established TCP connection with the 1137 next hop, if not, this node initiates a request for 1138 establishing the TCP connection, and after the connection is 1139 done, start KeepAlive timer. If the connection can not be 1140 established, then the node sends Notification message of 1141 "ShutDown", and the process goes to 8. 1143 3. Check whether PIB consists tables of DestPrefix and ToP, and 1144 judges whether the next hop in PIB is the one in routing 1145 tables: 1147 a. If so, insert the PID value of the table to PID Response 1148 Message, and forward the message to the upstream node, then 1149 the process goes to 8. 1151 b. If not,insert the PID value of the table to PID Release,and 1152 forward the message to the next hop, then delete the table. 1154 4. Check whether this node supports ToP traffic forwarding, if 1155 not, forward Notification message of " Internal Error" to the 1156 upstream node, then the process goes to 8. 1158 5. Check whether this node has residual PIDs, if not, forward 1159 Notification message of " No PID Resources" to the upstream 1160 node, then the process goes to 8. 1162 6. Forward the message of PID Request message to the next hop, and 1163 wait to receive the downstream message. 1165 7. The reply message received from the downstream nodes: 1167 a. If the message is PID Response, insert new tables which 1168 consist of DestPrefix, ToP, PID, NextPID, Nexthop etc.to PIB 1169 according to the PID value in reply message. Insert the PID 1170 value locally generated to PID Response Message, and forward 1171 the message to upstream nodes. 1173 b. If the message is Notification, then forward the message to 1174 upstream nodes 1176 8. Over 1178 4.2. Removal of the QTP-Path 1180 4.2.1 The trigger condition of removal process 1182 When the management plane determines to remove QTP-Path between two 1183 nodes, it carries out the removal process of QTP-Path through the 1184 control plane. The determination of QTP-Path removal can be obtained 1185 through the perception of network status and learning, or the network 1186 administrator manually configures. After the removal determination is 1187 made, the management plane gives the source node, destination node 1188 and business types, in this way, the control plane can carry out the 1189 removal process successfully. 1191 4.2.2 QTP-Path removal process 1193 The removal of QTP-Path starts from the source node and sends removal 1194 message along the path. 1196 The procedure in which node processes PID Release message is as 1197 follows: 1199 1. If the message comes from upstream nodes, forward it to 1200 downstream nodes; if it comes from downstream nodes; forward it 1201 to upstream nodes. 1203 2. If the value of PID equals to the value of WildCard, delete the 1204 tables in PIB which meets DestPrefix and ToP, else delete the 1205 tables in PIB which meets DestPrefix, ToP and PID 1207 4.3. QTP-Path adjustment process 1209 4.3.1 The trigger condition of QTP-Path adjustment 1211 When the management plane determines to adjust QTP-Path between two 1212 nodes, it carries out the adjustment process of QTP-Path through the 1213 control plane. The determination of QTP-Path adjustment can be 1214 obtained through the management plane's gathering business requests 1215 and the perception of network status, or the network administrator 1216 manually configures. Under the two conditions below, the management 1217 plane will adjust QTP-Path: 1219 1. A link of QTP-Path fails. 1221 2. A link or a section of QTP-Path congests, resulting in that 1222 data transmission can not meet business needs. Once the 1223 adjustment determination is made, the control plane needs the 1224 parameters of QTP-Path, e.g. source node, destination node, 1225 business types etc., after obtaining those parameters, the 1226 control plane will adjust QTP-Path according to the protocol. 1228 4.3.2 QTP-Path Adjustment Process 1230 When the management plane determines to adjust QTP-Path between two 1231 nodes, it sends QTP-Path establishment message to source nodes, then 1232 the source node sends PID Request message to downstream nodes. The 1233 adjustment process is similar to the establishment process. Because 1234 the adjustment of QTP-Path is based on the link availability or QoS 1235 performance, the adjustment process depends on the routing protocol 1236 on the node. 1238 5 Security Considerations 1240 TBA. 1242 6 IANA Considerations 1244 This memo includes no request to IANA. 1246 7 References 1248 7.1 Normative References 1250 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1251 Requirement Levels", BCP 14, RFC 2119, March 1997. 1253 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1254 Guidelines for DiffServ Service Classes", RFC 4594, August 1255 2006. 1257 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1258 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1259 Encoding", RFC 3032, January 2001. 1261 [I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A., 1262 Venkataramaiah, N., Wang, Y., Duda, K., Ganga, I., Lin, 1263 G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: 1264 Network Virtualization using Generic Routing 1265 Encapsulation", draft-sridharan-virtualization-nvgre-02 1266 (work in progress), February 2013. 1268 7.2 Informative References 1270 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1271 RFC 3514, April 1 2003. 1273 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1274 Acronyms", RFC 5513, April 1 2009. 1276 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1277 2009. 1279 Authors' Addresses 1281 Julong Lan 1282 National Digital Switching System Engineering and Technological 1283 Research Center 1284 NDSC, No.7 , Jianxue Street,Jinshui District 1285 Zhengzhou, 450002 1286 P.R.China 1288 Phone: +86-371-8163-2988 1289 Email: ndscljl@163.com 1290 URI: http://www.ndsc.com.cn/ 1292 Dongnian Cheng 1293 National Digital Switching System Engineering and Technological 1294 Research Center 1295 NDSC, No.7 , Jianxue Street,Jinshui District 1296 Zhengzhou, 450002 1297 P.R.China 1299 Phone: +86-371-8163-2743 1300 Email: cdn@mail.ndsc.com.cn 1301 URI: http://www.ndsc.com.cn/ 1303 Yuxiang Hu 1304 National Digital Switching System Engineering and Technological 1305 Research Center 1306 NDSC, No.7 , Jianxue Street,Jinshui District 1307 Zhengzhou, 450002 1308 P.R.China 1310 Phone: +86-371-8163-2737 1311 Email: chxachxa@126.com 1313 Guozhen Cheng 1314 National Digital Switching System Engineering and Technological 1315 Research Center 1316 NDSC, No.7 , Jianxue Street,Jinshui District 1317 Zhengzhou, 450002 1318 P.R.China 1320 Phone: +86-371-8163-2725 1321 Email: chengguozhen1986@163.com 1323 Zhiming Wang 1324 National Digital Switching System Engineering and Technological 1325 Research Center 1326 NDSC, No.7 , Jianxue Street,Jinshui District 1327 Zhengzhou, 450002 1328 P.R.China 1330 Phone: +86-371-8163-2651 1331 Email: wangzm05@gmail.com 1333 Lu Sun 1334 National Digital Switching System Engineering and Technological 1335 Research Center 1336 NDSC, No.7 , Jianxue Street,Jinshui District 1337 Zhengzhou, 450002 1338 P.R.China 1340 Phone: +86-371-8163-2846 1341 Email: sunlu@gmail.com