idnits 2.17.1 draft-viswanathan-mpls-rsvp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2-4' on line 206 -- Looks like a reference, but probably isn't: '6-8' on line 110 == Unused Reference: '6' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 541, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 545, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-rsvp-spec is -15, but you're referring to -16. ** Downref: Normative reference to an Informational RFC: RFC 1953 (ref. '2') == Outdated reference: A later version (-01) exists of draft-rekhter-tagswitch-arch-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Unexpected draft version: The latest known version of draft-ietf-intserv-guaranteed-svc is -07, but you're referring to -08. -- Unexpected draft version: The latest known version of draft-ietf-intserv-ctrl-load-svc is -04, but you're referring to -05. -- Possible downref: Normative reference to a draft: ref. '8' ** Downref: Normative reference to an Informational draft: draft-rfced-info-nagami (ref. '9') -- No information found for draft-davie-mpls-rsvp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-00 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Soft State Switching 3 A Proposal to Extend RSVP for Switching RSVP Flows 5 7 Status of This Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Abstract 27 This memo describes a mechanism for establishing a switched path with 28 guaranteed Quality of Service for RSVP [1] flows in a MultiProtocol 29 Label Switching (MPLS) environment. It proposes an extension to the 30 RSVP protocol that allows the establishment of a sequence of label 31 switched hops along the hop-by-hop routed path by enabling adjacent 32 nodes to exchange MPLS labels [11]. The labels may correspond to 33 information that identifies a layer 2 virtual connection; for 34 example, the VPI/VCI value in the case of an ATM-based 35 infrastructure. 37 1. Introduction 39 A Label Switching Router (LSR) is a label switching node that has an 40 IP Control Point (IP-CP) and implements an IP label switching 41 technology [2-4]. LSRs form adjacencies using a well-known label 42 switched path (LSP), also called the default path, that terminates at 43 the adjacent LSR's IP-CP. This hop-by-hop LSP connectivity gives a 44 network of LSRs the same nature as any ubiquitous IP internet. The 45 objective is to label switch RSVP flows in such an environment. 47 This document proposes an extension to RSVP that introduces new 48 objects to the existing RSVP messages. Using these objects, each 49 downstream LSR provides its neighboring upstream LSR with the label 50 on which it wishes to receive a RSVP flow. In an ATM-based LSR 51 environment, this label would correspond to a VPI/VCI value for the 52 ATM virtual circuit on which the LSR wishes to receive traffic from 53 the RSVP flow. Then, using an approach similar to those outlined in 54 [2], [3], and [4], the labels are spliced hop-by-hop to form an 55 ingress-to-egress LSP. The data from the RSVP flow then traverses 56 this LSP, and the RSVP signaling messages are forwarded hop-by-hop 57 via default paths. By moving RSVP flows from the hop-by-hop routed 58 path to a dedicated ingress-to-egress LSP, it is possible to leverage 59 the QoS capabilities of the underlying switching technology to 60 provide the type of service desired for the reserved flow. 62 The memo proposes a "one label per flow" approach, where a flow is 63 synonymous with a particular sender (source address/source port) and 64 session (destination address/protocol/destination port). It is 65 assumed here that the LSRs on the edge of a MPLS network can either 66 auto-learn or are configured to indicate that they are edge LSRs (on 67 a per interface basis). 69 2. Soft State Switching 71 In soft state switching, the goal is to switch packets from a RSVP 72 flow at layer 2 instead of having to forward them hop-by-hop as in 73 conventional IP routers. By doing so, it is possible to leverage the 74 high-performance switching and Quality of Service capabilities of the 75 layer 2 technology. This is achieved when all neighboring LSRs along 76 the routed path can exchange labels for establishing the switched 77 path for RSVP flows. Then, the labels may be "spliced" hop-by-hop 78 to set up an end-to-end (ingress-to-egress) LSP along the preferred 79 routed path. By splicing, we refer to the process by which an 80 incoming label is associated with an outgoing label at layer 2, 81 without traffic encapsulated by the incoming label being processed at 82 the network layer. For example, this can be achieved in ATM switches 83 by establishing this association in the ATM switching tables. Once 84 the splicing is complete, the default path carrying best effort 85 traffic between adjacent LSRs provides the IP forwarding path. The 86 RSVP signaling messages are forwarded on the default path. 88 The labels are assumed to have only unidirectional significance. In 89 other words, there exists a separate label space for each direction 90 of flow on a link. Moreover, the downstream LSR is chosen to be the 91 label space owner (allocator) on a link. The single owner approach 92 keeps the label usage simple and manageable. If a label space had 93 more than one owner, it would require that the owners synchronize 94 their use of the labels or the space would have to be partitioned 95 amongst the owners. For flexibility, the proposed extension to RSVP 96 also supports the concept of "upstream on demand" allocation as 97 described in [3]. In this method, the upstream LSR allocates labels 98 when demanded by a downstream LSR. This enables co-existence with 99 other protocols that consume labels. 101 3. Motivation 103 In this section, we discuss why the RSVP protocol is ideal for 104 establishing a label switched path for reserved flows. 106 One motivating factor for using RSVP is that mapping the network- 107 layer QoS request to a layer 2 virtual connection is simple. The 108 RESV message carries the QoS requested by the receiver(s) of the RSVP 109 flow. For example, this could correspond to one of the Integrated 110 Service classes described in [6-8]. This QoS information is needed 111 when layer 2 labels are set up and spliced; i.e., when the resource 112 reservations are made. Otherwise, the LSP establishment protocol 113 would have to carry its own QoS entity and/or map the label setup to 114 RSVP tables at each LSR hop. 116 Another motivating reason for extending RSVP is multicast support. 117 RSVP is designed to scale well for multicast sessions requiring 118 resource reservation. RSVP also allows receivers to join existing 119 sessions with different QoS requirements. An independent LSP 120 establishment protocol should be able to handle such session "joins" 121 equally well. 123 With the RSVP protocol the receivers can make sender selection 124 through the provision of different filter styles. In this, multiple 125 sender flows (as chosen by the receivers) in a RSVP session can be 126 associated with a single reservation. In other words, sender flows 127 in a RSVP session can be merged into a single downstream reservation. 128 A new LSP establishment protocol would have to support a similar 129 mechanism for seamless interoperability with the RSVP protocol. 131 Finally, any mechanism for setup of LSPs would, in any case, require 132 extensive interfacing with the RSVP protocol and/or its state tables. 134 Due to these reasons, it is best if RSVP can be extended without 135 changing its existing mechanics, to provide support for setting up 136 the switched path for RSVP flows. This need not be viewed as 137 "piggy-backing" another protocol on RSVP, but rather, a natural 138 extension to RSVP to provide QoS in a MPLS environment. 140 4. L2 Label Exchange Mechanism 142 The proposed extension to RSVP calls for adding a new object to carry 143 MPLS label information within RESV, PATH, and RESVERR messages. The 144 egress LSR, say LSR A, (i.e. the "last" node in the MPLS environment, 145 or the LSR through which the RSVP flow exits the MPLS environment) 146 will place this object in any RESV message that it sends to the PHOP 147 LSR for a flow (as stored in the Path state for this flow) -- call 148 this LSR B. The RESV message is sent to LSR B via the default routed 149 path. 151 If LSR B rejects the reservation (i.e., if the reservation is 152 rejected by either policy or admission control, or due to an error), 153 it then forwards a RESVERR message with the appropriate error code to 154 LSR A. The RESVERR message includes the MPLS label object received 155 from LSR A (RESVERR nack). Receipt of the RESVERR nack indicates 156 that the upstream LSR will not forward the reserved flow on the 157 requested LSP. In the event that this occurs, LSR A may choose to 158 release its reservation or it may choose to classify and forward 159 packets received on the default path from LSR B at the network layer. 161 If LSR B accepts the reservation, it will use the label in the RESV 162 message to setup a LSP to LSR A (in this case, the egress LSR) on the 163 outgoing interface. The QoS for this LSP corresponds to a mapping of 164 the Integrated Service class specified in the RESV message to an 165 appropriate set of QoS values for the layer 2 technology. LSR B will 166 forward a PATH message for the reserved flow to LSR A which includes 167 the MPLS label object allocated by LSR A (PATH ack). This MPLS label 168 object will also be included in all subsequent PATH messages for the 169 reserved flow sent to LSR A while the reservation remains in place. 171 LSR B will then choose a new label on the incoming interface through 172 which the RSVP flow enters the LSR, and send this label to its own 173 PHOP, LSR C, by passing the new MPLS label object in a RESV message. 174 LSR B may optimistically choose to splice the label on the incoming 175 interface from LSR C to the label on the outgoing interface to LSR A 176 by modifying its layer 2 label swap table, or it may choose to wait 177 for the receipt of a PATH ack from LSR C. If LSR C accepts the 178 reservation then it will forward a PATH ack to LSR B. If LSR C 179 rejects the reservation, it will then send a RESVERR nack to LSR B. 180 LSR B has the option of releasing its reservation (by transmitting a 181 RESVERR nack downstream to LSR A) or of classifying the packets of 182 the reserved flow on the default path from LSR C and forwarding them 183 on the previously established QoS LSP to LSR A, while sending a 184 RESVERR message without the label object to LSR A. 186 In the event of success at each PHOP LSR, the RESV will eventually 187 reach the ingress LSR (the LSR through which the RSVP flow enters the 188 MPLS environment). The ingress LSR will make necessary classifier 189 entries to forward packets for this flow through the LSP identified 190 by the label in the RESV message received from downstream. An 191 ingress LSR will delete the MPLS label object before forwarding a 192 RESV message to any of its PHOP nodes. The labels used for a RSVP 193 reservation are released whenever the RSVP reservation is torn down 194 or is timed-out. 196 Using this process, an end-to-end switched path is established for an 197 RSVP flow through a MPLS network. The data packets from the RSVP 198 flow are forwarded via this switched path, while RSVP control 199 messages continue to use the default paths between LSRs. 201 5. Partial QoS Paths 203 The procedure described in Section 4 must be clarified in the event 204 that the reserved traffic from a sender (source address/port) is 205 transported initially across a LSP from the ingress to the egress LSR 206 that has been established by an IP switching protocol [2-4, 9]. In 207 this case, the best-effort packets are not forwarded along the hop- 208 by-hop default path and processed at the network layer within each 209 intermediate LSR, but are instead forwarded along a series of spliced 210 label switched hops, and hence are not normally available for packet 211 classification. If a reservation should succeed all the way back to 212 the ingress LSR for a reserved flow, that LSR will classify the 213 packets from the flow and move them onto the new ingress-to-egress 214 QoS LSP. 216 However, if the reservation succeeds on some of the LSRs on the 217 reverse path from the egress but not all the way back to the ingress, 218 then QoS for the flow cannot be achieved on the path through the LSRs 219 which accepted the reservation unless the farthest upstream LSR which 220 accepted the reservation unsplices the best-effort LSP, classifies 221 the packets of the reserved flow, and forwards them on the QoS LSP to 222 the egress LSR. Note that the default behavior of RSVP is to allow 223 partial QoS paths from the receiver back towards the sender by 224 allowing reservations which have succeeded at a node to remain in 225 place in the event that the reservation fails further upstream. 227 Because it is likely that some LSRs will lack sufficient network- 228 layer forwarding capability to unsplice and route many best-effort 229 LSPs simultaneously, the behavior of a LSR which has accepted a 230 reservation, established a QoS LSP on the appropriate downstream 231 interface(s), but subsequently receives a RESVERR nack from upstream 232 should be configurable. In the event that the LSR chooses to 233 classify the reserved flow at the network layer by unsplicing the 234 best-effort LSP, there are no required changes to the protocol 235 exchange described in Section 4. However, if the LSR chooses to 236 release the reservation, then it should transmit a RESVERR nack 237 downstream and establish blockade state for the reservation. 238 Subsequent reservations for the flow with an equal or greater 239 flowspec should be rejected and blockaded until the blockade timer 240 expires. This prevents the establishment of a potentially unused QoS 241 LSP through the LSR until the blockade timer for the reservation 242 expires. Reservations for the flow with a strictly smaller flowspec 243 can be accepted and propagated upstream. Receipt of a RESVERR nack 244 should be taken as definitive, even if it immediately follows (or 245 precedes) a PATH ack. 247 Another alternative is to continue to propagate RESV messages and 248 labels all the way to the ingress LSR, with an indication that the 249 reservation has failed somewhere downstream, and that QoS need not 250 be provided for the upstream segments of the LSP. These RESV 251 messages would terminate at the ingress LSR without generating a 252 RESVERR message on any node upstream of the reservation failure. 253 This approach would entail modifications to the RSVP message 254 processing rules. 256 6. Merging 258 RSVP scales by merging reservation requests as they propagate 259 upstream towards senders, and by merging QoS handling state as the 260 data flows propagate downstream towards the receivers. The ability 261 to perform merging in a LSR environment is dependent on the switching 262 capabilities of the LSRs. 264 There are several switching technologies available today (ATM, Frame 265 Relay etc.) and perhaps more in the future. Moreover, the 266 capabilities of a switch of a certain technology vary from vendor to 267 vendor. Three basic characteristics are identified that determine 268 how the underlying switching technology can be used in conjunction 269 with this proposal to address merging of flows under the appropriate 270 environment. They are: 272 o Attribute A: Can correctly merge several upstream LSPs into a 273 single downstream LSP ("VC merge"). Frame switches are 274 typically able to do this in a straightforward manner. 275 However, for ATM switches without appropriate functionality 276 built in, cells from different AAL SDUs may become interleaved 277 on the outgoing VC (LSP), thus corrupting the higher-layer 278 information. 280 o Attribute B: Can treat a set of labels as a single entity for 281 QoS purposes. A switch with this property is able to treat all 282 traffic from a set of labels in a like manner for purposes of 283 scheduling, fair queueing etc. For example, an ATM switch that 284 performs per-class queueing would assign all the VCs from a 285 given set to a particular class. Then, cells from all the VCs 286 in the sets would receive the QoS corresponding to that class. 288 o Attribute C: Can demultiplex senders flows in a single LSP into 289 a separate LSP for a sender. For example, using the label 290 stack for L2 tunneling [3,4]. 292 One logical candidate for flow merging would be support for shared 293 explicit and wildcard reservations, where resources are shared among 294 a set of multiple senders. The difficulty this poses is the 295 potential need to demultiplex senders from the merged flow for 296 downstream receivers which have made reservations for only a subset 297 of the senders, as described in [10]. Merging of multiple sender 298 LSPs into a single LSP (Attribute A) requires support for Attribute C 299 in the LSRs to permit sender demultiplexing. Support for Attribute B 300 permits LSRs to share QoS resources among a group of per-sender LSPs 301 while still facilitating sender demultiplexing. 303 7. Multicast Support 305 7.1 Packet Replication 307 In order to support multicast sessions, at split points within the 308 MPLS network, where data from upstream LSRs splits into multiple 309 downstream flows, the LSR can perform the required duplication (at 310 layer 2) of packets by utilizing the hardware multicast capability 311 (for example, point-to-multipoint VC) of the switch, if available. 312 Otherwise, the flow has to be processed at the network layer and 313 multicast in the normal manner. Note that network layer forwarding 314 is interoperable with all switch types. 316 7.2 Packet Duplication 318 In configurations where a per-source or shared multicast tree is 319 mapped to a point-to-multipoint LSP rooted at an ingress LSR and 320 terminating at each egress LSR with one or more downstream receivers, 321 packet duplication can occur if receivers make a reservation for a 322 particular flow initially being carried on the multicast LSP. This 323 occurs because the flow's packets are carried on both the best-effort 324 and QoS LSP, which are delivered to each egress LSR on the multicast 325 tree. This problem can be avoided if the packets of the reserved 326 flow are removed from the best-effort multicast LSP and carried only 327 on the QoS LSP. 329 7.3 Unreserved Receivers 331 When none of the receivers have made a reservation, the multicast 332 session may flow through the default multicast LSP as best-effort 333 traffic. But as soon as a receiver makes a reservation, and packets 334 from the reserved flow are removed from the best-effort LSP, the data 335 flow may stop to receivers that have not made a reservation. The 336 receivers without a reservation only get PATH messages but no data 337 (even at best-effort). This problem can be addressed in several 338 different ways determined by the switch architecture. 340 This problem can be avoided for switches that support Attribute A. 341 They can add the default best-effort LSP for the (source/)group as a 342 branch in the point-to-multipoint per-flow QoS LSP by merging the QoS 343 LSP back onto the best-effort LSP on those branches of the tree where 344 there are no downstream receivers. If the switch architecture allows 345 adding the local IP-CP to the point-to-multipoint QoS LSP, then the 346 IP-CP can multicast the packets only to those interfaces from which 347 there is no reservation but which are listed in the multicast table. 349 If the switch architecture does not support Attribute A, and can not 350 efficiently perform the multicast forwarding in the IP-CP, then one 351 approach is to build the per-flow QoS LSP to all egress LSRs on the 352 multicast tree (whether they forwarded a RESV or not). The QoS on 353 each branch of this point-to-multipoint LSP would be configured based 354 on the amount of resources reserved on that branch. For best-effort 355 branches, a UBR-like QoS would be used. The LSP construction could 356 be performed under the control of the ingress LSR rooting the 357 multicast tree. Another way to construct the LSP is to use a PATH 358 message to perform the LSP establishment from the node downstream of 359 which there are interfaces through which no reservation has been 360 received. This would be initiated whenever there is at least one 361 reservation in place at the node for the RSVP flow. This may not 362 work in environments where upstream label allocation is not 363 permitted. 365 7.4 Shared Media Label Allocation 367 This memo describes a RSVP extension for the MPLS environment where 368 the downstream LSR is the label space owner. As discussed in [5] and 369 [10], this can lead to an allocation deadlock if the downstream 370 receivers on a shared media subnet cannot agree on the value for the 371 label. One approach suggested in [10] is to permit a receiver to 372 suggest a label by passing one upstream in a RESV message, but to 373 allow the upstream node to select the definitive label and pass it 374 downstream within a PATH ack. 376 Another alternative is to support upstream on demand allocation. 377 In this case, a receiver forwards a RESV message using a NULL MPLS 378 label object to indicate a request for label allocation. The 379 upstream LSR will respond with a label for the RSVP flow in the PATH 380 message to the downstream neighbors. The downstream receivers are 381 responsible for using the label selected by the upstream node, and 382 should include this label in all subsequent RESV messages. In the 383 event that the label selected upstream is out-of-range for a 384 particular receiver, then the receiver can forward a new RESV message 385 with a NULL MPLS label object to trigger a new label allocation. 386 Note that a PATHERR message is not suitable for communicating this 387 error since it propagates all the way back to the sender. 389 The flexibility of upstream on demand label allocation is also useful 390 in non-shared media environments as it allows co-existence with other 391 IP switching protocols. 393 8. TTL Decrement 395 When IP packets flow through a switched path, the TTL value in the IP 396 header cannot be decremented. The decrementing of the TTL value is 397 used to delete packets in a routing loop to avoid/reduce congestion. 398 For this purpose, the proposed LSR Hop Count Object carries a hop- 399 count that counts the number of consecutive LSR hops. The LSRs 400 increment the hop-count only if there is a switched path for that 401 sender flow through that LSR. All LSRs maintain the hop count in the 402 Path state. Only the egress LSR on which the LSP terminates would use 403 the count to decrement the TTL on packets for that sender flow. The 404 LSRs of a switching technology that have a TTL equivalent in the layer 405 2 header may choose not to use the LSR Hop Count Object. 407 9. Adjacency 409 LSR neighbors need some mechanism to establish adjacencies. This is 410 required because the neighbors need to exchange the label range for 411 correct label allocation. They also need to elect the label 412 allocator. The current version of this memo does not propose any 413 extension to the RSVP protocol for this mechanism. It is assumed 414 that adjacency would be established by another protocol (as proposed 415 in [2], [3] or [4]) and such information would be made available to 416 the RSVP module. In the absence of such a mechanism the LSRs would 417 have to be configured with the required information to operate as 418 described in this memo. 420 10. Object Formats 422 This section describes the object formats for the proposed extension. 423 The label objects for ATM LSRs are defined below. Label formats for 424 additional link-layer media will be proposed in a future revision of 425 this memo. 427 o LSR HOP COUNT object: Class = x, C-Type = 1 429 +-------------+-------------+-------------+-------------+ 430 | Hop Count | Reserved | 431 +-------------+-------------+-------------+-------------+ 433 Hop Count 434 Counts the length (in LSR hops) of the switched path. 436 o NULL Label Object: Class = y, C-Type = 1 438 o ATM RESV Label object: Class = y, C-Type = 2 440 +-------------+-------------+-------------+-------------+ 441 | IPv4 SrcAddress (4 bytes) | 442 +-------------+-------------+-------------+-------------+ 443 | ////// | ////// | SrcPort | 444 +-------+-----+-------------+-------------+-------------+ 445 | Flags | VPI | VCI | 446 +-------+-------------------+-------------+-------------+ 447 // // 448 +-------------+-------------+-------------+-------------+ 449 | IPv4 SrcAddress (4 bytes) | 450 +-------------+-------------+-------------+-------------+ 451 | ////// | ////// | SrcPort | 452 +-------+-----+-------------+-------------+-------------+ 453 | Flags | VPI | VCI | 454 +-------+-------------------+-------------+-------------+ 456 IPv4 SrcAddress 457 IPv4 address of the sender. 459 Flags - 4 bits 460 0x01 - Implies that the reservation is not in place in the 461 node forwarding the RESVERR message and that the reserved 462 traffic is not being forwarded via the VC (RESVERR nack). 464 VPI - 12 bits 465 Virtual Path Identifier. If less than 12 bits are 466 significant, then it is right justified in this field. 468 VCI - 16 bits 469 Virtual Circuit Identifier. If less than 16 bits are 470 significant, then it is right justified in this field. 472 o ATM PATH Label object: Class = y, C-Type = 3 474 +-------+-------------------+-------------+-------------+ 475 | Flags | VPI | VCI | 476 +-------+-------------------+-------------+-------------+ 478 Flags - 4 bits 479 0x01 - Implies that the PATH message is in response to an 480 upstream on demand label allocation and may not be 481 propagated any further. 483 0x02 - Implies that the PATH message is in response to a 484 RESV message carrying a RESV Label object (PATH ack) and 485 may not be propagated any further. 487 VPI - 12 bits 488 Virtual Path Identifier. If less than 12 bits are 489 significant, then it is right justified in this field. 491 VCI - 16 bits 492 Virtual Circuit Identifier. If less than 16 bits are 493 significant, then it is right justified in this field. 495 The IPv6 extension and error codes will be defined in a later 496 revision of this memo. 498 The reader may have noticed that the new ATM RESV Label object has 499 duplicated information already present in the FILTER_SPEC object. 500 Another approach could be to extend the FILTER_SPEC object definition 501 to carry the link-layer labels or insert the label object following 502 the FILTER_SPEC object. 504 11. Security Considerations 506 Security considerations are not discussed in this memo. 508 12. Acknowledgements 510 The authors wish to acknowledge Shailendra Bhatnagar, Nancy Feldman, 511 Liang Li, Steve Nadas, and Bruce Sinclair for their input. 513 13. References 515 [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource 516 ReSerVation Protocol (RSVP) -- Version 1 Functional 517 Specification. Internet Draft, draft-ietf-rsvp-spec-16, 518 June 1997. 520 [2] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, 521 T. Lyon, G. Minshall, Ipsilon Flow Management Protocol 522 Specification for IPv4, Version 1.0. Internet RFC 1953, 523 May 1996. 525 [3] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. 526 Farinacci, Tag Switching Architecture - Overview. Internet 527 Draft, draft-rekhter-tagswitch-arch-00.txt, January 1997. 529 [4] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, ARIS: 530 Aggregated Route-Based IP Switching. Internet Draft, 531 draft-viswanathan-aris-overview-00.txt, March 1997. 533 [5] D. Farinacci, Partitioning Tag Space among Multicast Routers on 534 a Common Subnet. Internet Draft, 535 draft-farinacci-multicast-tag-part-00.txt, December 1996. 537 [6] S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed 538 Quality of Service. Internet Draft, 539 draft-ietf-intserv-guaranteed-svc-08.txt, February 1997. 541 [7] J. Wroclawski, Specification of the Controlled-Load Network 542 Element Service. Internet Draft, 543 draft-ietf-intserv-ctrl-load-svc-05.txt, May 1997. 545 [8] F. Baker, R. Guerin, D. Kandlur, Specification of Committed Rate 546 Quality of Service. Internet Draft, 547 draft-ietf-intserv-commit-rate-svc-00.txt, June 1996. 549 [9] K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, 550 T. Jinmei, H. Esaki, Flow Attribute Notification Protocol (FANP) 551 Specification, Internet Draft, draft-rfced-info-nagami-00.txt, 552 February 1997. 554 [10] B. Davie, Y. Rekhter, E. Rosen, Use of Label Switching With 555 RSVP, Internet Draft, draft-davie-mpls-rsvp-00.txt, May 1997. 557 [11] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 558 A. Viswanathan, A Framework for Multiprotocol Label Switching, 559 Internet Draft, draft-ietf-mpls-framework-00.txt, May 1997. 561 Author's Address 563 Arun Viswanathan 564 IBM Corporation 565 17 Skyline Drive 566 Hawthorne, NY 10532 567 Phone: +1 (914) 784-3273 568 Email: arunv@vnet.ibm.com 570 Vijay Srinivasan 571 IBM Corporation 572 PO Box 12195 573 Research Triangle Park, NC 27709 574 Phone: +1 (919) 254-2730 575 Email: vijay@raleigh.ibm.com 577 Steven Blake 578 IBM Corporation 579 PO Box 12195 580 Research Triangle Park, NC 27709 581 Phone: +1 (919) 254-2030 582 Email: slblake@raleigh.ibm.com