idnits 2.17.1 draft-shiomoto-ccamp-switch-programming-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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 18, 2011) is 4693 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group K. Shiomoto 3 Internet-Draft NTT 4 Intended Status: Informational 5 A. Farrel 6 Expires: December 18, 2011 Old Dog Consulting 7 June 18, 2011 9 Advice on When It is Safe to Start Sending Data on 10 Label Switched Paths Established Using RSVP-TE 12 draft-shiomoto-ccamp-switch-programming-05.txt 14 Abstract 16 The Resource Reservation Protocol (RSVP) has been extended to support 17 Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) networks. The protocol enables signaling 19 exchanges to establish Label Switched Paths (LSPs) that traverse 20 nodes and links to provide end-to-end data paths. Each node is 21 programmed with "cross-connect" information as the signaling messages 22 are processed. The cross-connection information instructs the node 23 how to forward data that it receives. 25 End points of an LSP need to know when it is safe to start sending 26 data so that it is not misdelivered, and so that safety issues 27 specific to optical data plane technology are satisfied. Likewise, 28 all label switching routers along the path of the LSP need to know 29 when to program their data planes relative to sending and receiving 30 control plane messages. 32 This document clarifies and summarises the RSVP-TE protocol exchanges 33 with relation to the programming of cross-connects along an LSP for 34 both unidirectional and bidirectional LSPs. This document does not 35 define any new procedures or protocol extensions, and defers 36 completely to the documents that provide normative references. The 37 clarifications set out in this document may also be used to help 38 interpret LSP establishment performance figures for MPLS-TE and GMPLS 39 devices. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 7, 2011. 58 Copyright Notice 60 Copyright (c) 2010 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 1. Introduction 75 The Resource Reservation Protocol (RSVP) [RFC2205] has been extended 76 to support Traffic Engineering (TE) in Multiprotocol Label Switching 77 (MPLS) and Generalized MPLS (GMPLS) networks [RFC3209], [RFC3473]. 78 The protocol enables signaling exchanges to establish Label Switched 79 Paths (LSPs) that traverse nodes and links to provide end-to-end data 80 paths. Each node is programmed with "cross-connect" information as 81 the signaling messages are processed. The cross-connection 82 information instructs the node how to forward data that it receives. 83 In some technologies this requires configuration of physical devices, 84 while in others it may involve the exchange of commands between 85 different components of the node. The nature of a cross-connect is 86 described further in Section 1.1.1. 88 End points of an LSP need to know when it is safe to start sending 89 data. In this context "safe" has two meanings. The first issue is 90 that the sender needs to know that the data path has been fully 91 established, setting up the cross-connects and removing any old, 92 incorrect forwarding instructions, so that data will be delivered to 93 the intended destination. The other meaning of "safe" is that in 94 optical technologies lasers must not be turned on until the correct 95 cross-connects have been put in place to ensure that service 96 personnel are not put at risk. 98 Similarly, all Label Switching Routers (LSRs) along the path of the 99 LSP need to know when to program their data planes relative to 100 sending and receiving control plane messages. 102 This document clarifies and summarises the RSVP-TE protocol exchanges 103 with relation to the programming of cross-connects along an LSP for 104 both unidirectional and bidirectional LSPs. Bidirectional LSPs, it 105 should be noted, are supported only in GMPLS. This document does not 106 define any new procedures or protocol extensions, and defers 107 completely to the documents that provide normative references. 109 The clarifications set out in this document may also be used to help 110 interpret LSP establishment performance figures for MPLS-TE and GMPLS 111 devices. For example, the dynamic provisioning performance metrics 112 set out in [RFC5814] need to be understood in the context of LSP 113 setup times and not in terms of control message exchange times that 114 are actually only a component of the whole LSP establishment process. 116 It would be really useful to implementations for this document to 117 definitively identify when it is safe for any LSR to forward the Path 118 or Resv message [RFC3473] before programming its cross-connect, 119 thereby exploiting pipelining (i.e., doing one action in the 120 background while another is progressing) to try to minimise the total 121 time to set up the LSP. However, while this document gives advice and 122 identifies the issues to be considered, it is not possible to make 123 definitive statements about how much pipelining is safe, since a node 124 cannot "know" much without first probing the network (for example, 125 with protocol extensions) and that would defeat the point of 126 pipelining. There are so many variables introduced by path length and 127 by the behavior of other nodes that an ingress might be limited to a 128 very pessimistic view for safety. Furthermore, it seems unlikely that 129 an implementation would necessarily give a full and frank description 130 of how long it takes to program and stabilize its cross-connects. 131 Nevertheless, this document identifies the issues and opportunities 132 for pipelining in GMPLS systems. 134 1.1. Terminology 136 It is assumed that the reader is familiar with the basic message 137 flows of RSVP-TE as used in MPLS-TE and GMPLS. Refer to [RFC2205], 138 [RFC3209], [RFC3471], and [RFC3473] for more details. 140 1.1.1. What is a Cross-Connect? 142 In the context of this document, the concept of a "cross-connection" 143 should be taken to imply the data forwarding instructions installed 144 (that is, "programmed") at a network node (or "switch"). 146 In packet MPLS networks, this is often referred to as the Incoming 147 Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) [RFC3031] 148 which are sometimes considered together as entries in the Label 149 Forwarding Information Base (LFIB) [RFC4221]. Where there is 150 admission control and resource reservation associated with the data 151 forwarding path (such as the allocation of data buffers) [RFC3209] 152 this can be treated as part of the cross-connect programming process 153 since before the resources are correctly allocated and reserved, the 154 LSP will not be available to forward data in the manner agreed to 155 during the signaling protocol exchange. 157 In non-packet networks (such as time-division multiplexing, or 158 optical switching networks) the cross-connect concept may be an 159 electronic cross-connect array or a transparent optical device (such 160 as a microelectromechanical system (MEMS)). In all cases, however, 161 the concept applies to the instructions that are programmed into the 162 forwarding plane (that is, the data plane) so that incoming data for 163 the LSP on one port can be correctly handled and forwarded out of 164 another port. 166 2. Unidirectional MPLS-TE LSPs 168 [RFC3209] describes the RSVP-TE signaling and processing for MPLS-TE 169 packet-based networks. LSPs in these networks are unidirectional by 170 definition (there are no bidirectional capabilities in [RFC3209]). 172 Section 4.1.1.1 of [RFC3209] describes the processing that a node 173 does before sending a Resv message to its upstream neighbor. 175 "The node then sends the new LABEL object as part of the Resv 176 message to the previous hop. The node SHOULD be prepared to 177 forward packets carrying the assigned label prior to sending the 178 Resv message." 180 This means that the cross-connect should be in place to support 181 traffic that may arrive at the node before the node sends the Resv. 182 This is clearly advisable because the upstream LSRs might otherwise 183 complete their cross-connections more rapidly and encourage the 184 ingress to start transmitting data with the risk that the node that 185 sent the Resv "early" would be unable to forward the data it received 186 and would be forced to drop it, or might accidentally send it along 187 the wrong LSP because of stale cross-connect information. 189 The use of "SHOULD" [RFC2119] in this text indicates that an 190 implementation could be constructed that sends a Resv before it is 191 ready to receive and forward data. This might be done simply because 192 the internal construction of the node means that the control plane 193 components cannot easily tell when the cross-connection has been 194 installed. Alternatively it might arise because the implementation is 195 aware that it will be slow and does not wish to hold up the 196 establishment of the LSP. In this latter case, the implementation is 197 choosing to pipeline the cross-connect programming with the protocol 198 exchange taking a gamble that there will be other upstream LSRs that 199 may also take some time to process, and it will in any case be some 200 time before the ingress actually starts to send data. It should be 201 noted that, as well as the risks described in the previous paragraph, 202 a node that behaves like this must include a mechanism to report a 203 failure to chase the Resv message (using a PathErr) in the event that 204 the pipelined cross-connect processing fails. 206 3. GMPLS LSPs 208 GMPLS [RFC3945] extends RSVP-TE signaling for use in networks of 209 different technologies [RFC3471], [RFC3473]. This means that RSVP-TE 210 signaling may be used in MPLS packet switching networks, as well as 211 layer two networks (Ethernet, Frame Relay, ATM), time-division 212 multiplexing networks (TDM, i.e., SONET and SDH), wavelength division 213 multiplexing networks (WDM), and fiber switched network. 215 The introduction of these other technologies, specifically the 216 optical technologies, brings about the second definition of the 217 "safe" commencement of data transmission as described in Section 1. 218 That is, there is a physical safety issue that means that the lasers 219 should not be enabled until the cross-connects are correctly in 220 place. 222 GMPLS supports unidirectional and bidirectional LSPs. These are split 223 into separate sections for discussion. The processing rules are 224 inherited from [RFC3209] unless they are specifically modified by 225 [RFC3471] and [RFC3473]. 227 3.1. Unidirectional LSPs 229 Unidirectional LSP processing would be the same as that described in 230 Section 2 except for the use of the Suggested_Label object defined in 231 [RFC3473]. This object allows an upstream LSR to 'suggest' to its 232 downstream neighbor the label that should be used for forward- 233 direction data by including the object on a Path message. The purpose 234 of this object is to help the downstream LSR in its choice of label, 235 but it also makes it possible for the upstream LSR to 'pipeline' 236 programming its cross-connect with the RSVP-TE signaling exchanges. 237 That means that the cross-connect might be in place before the 238 signaling has completed (i.e., before a Resv message carrying a Label 239 object has been received at the upstream LSR). 241 We need to know when it is safe to start sending data. There are 242 three sources of information. 244 - Section 3.4 of [RFC3471] states: 246 "In particular, an ingress node should not transmit data traffic 247 on a suggested label until the downstream node passes a label 248 upstream." 250 The implication here is that an ingress node may (safely) start to 251 transmit data when it receives a label in a Resv message. 253 - Section 2.5 of [RFC3473] states: 255 "Furthermore, an ingress node SHOULD NOT transmit data traffic 256 using a suggested label until the downstream node passes a 257 corresponding label upstream." 259 This is a confirmation of the first source. 261 - Section 4.1.1.1 of [RFC3209] states: 263 "The node then sends the new LABEL object as part of the Resv 264 message to the previous hop. The node SHOULD be prepared to 265 forward packets carrying the assigned label prior to sending the 266 Resv message." 268 In this text the word "prior" is very important. It means that the 269 cross-connect must be in place for forward traffic before the Resv 270 is sent. In other words, each of the the transit nodes and the 271 egress node must finish making their cross-connects before they 272 send the Resv message to their upstream neighbors. 274 Thus, as in Section 2, we can deduce that the ingress must not start 275 to transmit traffic until it has both received a Resv and has 276 programmed its own cross-connect. 278 3.2. Bidirectional LSPs 280 A bidirectional LSP is established with one signaling exchange of a 281 Path message from ingress to egress, and a Resv from egress to 282 ingress. The LSP itself is comprised of two sets of forwarding state, 283 one providing a path from the ingress to the egress (the forwards 284 data path), and one from the egress to the ingress (the reverse 285 data path). 287 3.2.1. Forwards Direction Data 289 The processing for the forwards direction data path is exactly as 290 described for a unidirectional LSP in Section 3.1. 292 3.2.2. Reverse Direction Data 294 For the reverse direction data flow an Upstream_Label object is 295 carried in the Path message from each LSR to its downstream neighbor. 296 The Upstream_Label object tells the downstream LSR which label to use 297 for data being sent to the upstream LSR (that is, reverse direction 298 data). The use of the label is confirmed by the downstream LSR when 299 it sends a Resv message. Note that there is no explicit confirmation 300 of the label in the Resv message, but if the label was not acceptable 301 to the downstream LSR, it would return a PathErr message instead. 303 The upstream LSR must decide when to send the Path message relative 304 to when it programs its cross-connect. That is: 306 - Should it program the cross-connect before it sends the Path 307 message; 309 - Can it overlap the programming with the exchange of messages; or 311 - Must it wait until it receives a Resv from its downstream neighbor? 313 The defining reference is Section 3.1 of [RFC3473]: 315 "The Upstream_Label object MUST indicate a label that is valid for 316 forwarding at the time the Path message is sent." 318 In this text "valid for forwarding" should be taken to mean that it 319 is safe for the LSR that sends the Path message to receive data, and 320 that the LSR will forward data correctly. The text does not mean that 321 the label is "acceptable for use" (i.e., the label is available to be 322 cross-connected). 324 This point is clarified later in Section 3.1 of [RFC3473]: 326 "Terminator nodes process Path messages as usual, with the 327 exception that the upstream label can immediately be used to 328 transport data traffic associated with the LSP upstream towards the 329 initiator." 331 This is a clear statement that when a Path message has been fully 332 processed by an egress node, it is completely safe to transmit data 333 toward the ingress (i.e., reverse direction data). 335 From this we can deduce several things: 337 - An LSR must not wait to receive a Resv message before it programs 338 the cross-connect for the reverse direction data. It must be ready 339 to receive data from the moment that the egress completes 340 processing the Path message that it receives (i.e., before it sends 341 a Resv back upstream). 343 - An LSR may expect to start receiving reverse direction data as soon 344 as it sends a Path message for a bidirectional LSP. 346 - An LSR may make some assumptions about the time lag between sending 347 a Path message and the message reaching and being processed by the 348 egress. It may take advantage of this time lag to pipeline 349 programming the cross-connect. 351 3.3. ResvConf Message 353 The ResvConf message is used in standard RSVP [RFC2205] to let the 354 ingress confirm to the egress that the Resv has been successfully 355 received, and what bandwidth has been reserved. In RSVP-TE [RFC3209] 356 and GMPLS [RFC3473], it is not expected that bandwidth will be 357 modified along the path of the LSP, so the purpose of the ResvConf 358 is reduced to a confirmation that the LSP has been successfully 359 established. 361 The egress may request that a ResvConf is sent by including a 362 Resv_Confirm object in the Resv message that it sends. When the 363 ingress receives the Resv message and sees the Resv_Confirm object, 364 it can respond with a ResvConf message. 366 It should be clear that this mechanism might provide a doubly secure 367 way for the egress to ensure that the reverse direction data path is 368 safely in place before transmitting data. That is, if the egress 369 waits until it receives a ResvConf message, it can be sure that the 370 whole LSP is in place. 372 However, this mechanism is excessive given the definitions presented 373 in Section 3.2.2, and would delay LSP setup by one end-to-end message 374 propagation cycle. It should be noted as well that the generation and 375 of the ResvConf message is not guaranteed. Furthermore, many (if not 376 most) GMPLS implementations neither request nor send ResvConf 377 messages. Therefore, an egress is not recommended to rely on the 378 receipt of a ResvConf as a way of knowing that it is safe to start 379 transmitting reverse direction data. 381 3.4. Administrative Status 383 GMPLS offers an additional tool for ensuring safety of the LSP. The 384 Administrative Status information is defined in Section 8 of 385 [RFC3471] and is carried in the Admin_Status Object defined in 386 Section 7. of [RFC3473]. 388 This object allows an ingress to set up an LSP in "Administratively 389 Down" state. This state means ([RFC3471] that: 391 "... the local actions related to the "administratively down" state 392 should be taken." 394 In this state it is assumed that the LSP exists (i.e., the cross- 395 connects are all in place), but no data is transmitted (i.e., in 396 optical systems, the lasers are off ). 398 Additionally, the Admin_Status object allows the LSP to be put into 399 "Testing" state. This state means ([RFC3471]) that: 401 "... the local actions related to the "testing" mode should be 402 taken." 404 This state allows the connectivity of the LSP to be tested without 405 actually exchanging user data. For example, in an optical system it 406 would be possible to run a data continuity test (using some external 407 coordination of errors). In a packet network, a connection 408 verification exchange (such as the in-band Virtual Circuit 409 Connectivity Verification described in Section 5.1.1 of [RFC5085]) 410 could be used. Once connectivity has been verified, the LSP could be 411 put into active mode and the exchange of user data could commence. 413 These processes may be considered particularly important in systems 414 where the control plane processors are physically distinct from the 415 data plane cross-connects (for example, where there is a 416 communication protocol operating between the control plane processor 417 and the data plane switch) in which case the successful completion of 418 control plane signaling cannot necessarily be taken as evidence of 419 correct data plane programming. 421 4. Implications for Performance Metrics 423 The ability of LSRs to handle and propagate control plane messages 424 and to program cross-connects varies considerably from device to 425 device according to switching technology, control plane connectivity, 426 and implementation. These factors influence how quickly an LSP can be 427 established. 429 Different applications have different requirements for the speed of 430 setup of LSPs, and this may be particularly important in recovery 431 scenarios. It is important for service providers considering the 432 deployment of MPLS-TE or GMPLS equipment to have a good benchmark for 433 the performance of the equipment. Similarly, it is important for 434 equipment vendors to be compared on a level playing field. 436 In order to provide a basis for comparison, [RFC5814] defines a 437 series of performance metrics to evaluate dynamic LSP provisioning 438 performance in MPLS-TE/GMPLS networks. Any use of such metrics must 439 be careful to understand what is being measured bearing in mind that 440 it is not enough to know that the control plane message has been 441 processed and forwarded: the cross-connect must be put in place 442 before the LSP can be used. Thus, care must be taken to ensure that 443 devices are correctly conforming to the procedures clarified in 444 Section 2 of this document, and not simply forwarding control plane 445 messages with the intent to program the cross-connects in the 446 background. 448 5. IANA Considerations 450 This document makes no requests for IANA action. 452 6. Security Considerations 454 This document does not define any network behavior and does not 455 introduce or seek to solve any security issues. 457 It may be noted that a clear understanding of when to start sending 458 data may reduce the risk of data being accidentally delivered to the 459 wrong place, or individuals being hurt. 461 7. Acknowledgments 463 Thanks to Weiqiang Sun, Olufemi Komolafe, Daniel King, and Stewart 464 Bryant for their review and comments. 466 8. References 468 8.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and S. 474 Jamin, "Resource ReserVation Protocol -- Version 1 475 Functional Specification", RFC 2205, September 1997. 477 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 478 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 479 Tunnels", RFC 3209, December 2001. 481 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 482 Switching (GMPLS) Signaling Functional Description", RFC 483 3471, January 2003. 485 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 486 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 487 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 489 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 490 Switching (GMPLS) Architecture", RFC 3945, October 2004. 492 8.2. Informative References 494 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 495 Label Switching Architecture", RFC 3031, January 2001. 497 [RFC4221] Nadeau, T., Srinivasan, C., and Farrel, A., "Multiprotocol 498 Label Switching (MPLS) Management Overview", RFC 4221, 499 November 2005. 501 [RFC5085] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 502 Connectivity Verification (VCCV): A Control Channel for 503 Pseudowires", RFC 5085, December 2007. 505 [RFC5814] Sun, W., and Zhang, G., "Label Switched Path (LSP) Dynamic 506 Provisioning Performance Metrics in Generalized MPLS 507 Networks", RFC 5814, March 2010. 509 Authors' Addresses 511 Kohei Shiomoto 512 NTT Network Service Systems Laboratories 513 3-9-11 Midori 514 Musashino, Tokyo 180-8585 515 Japan 516 Phone: +81 422 59 4402 517 Email: shiomoto.kohei@lab.ntt.co.jp 519 Adrian Farrel 520 Old Dog Consulting 521 Email: adrian@olddog.co.uk