idnits 2.17.1 draft-ietf-pwe3-fc-flow-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 abstract seems to contain references ([FC-encap]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: An N(S) sequence error exception condition occurs in the receiver when a received SR-I message contains an N(S) that is not equal to the receive state variable V(R) at the receiver. The receiver SHALL not acknowledge (i.e., increment its receive state variable) the SR-I message causing the sequence error, or any SR-I message that may follow, until an SR-I message with the correct N(S) is received. -- The document date (January 15, 2009) is 5552 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) -- Looks like a reference, but probably isn't: '1' on line 62 == Missing Reference: 'RFC4448' is mentioned on line 94, but not defined == Missing Reference: 'RFC4619' is mentioned on line 95, but not defined == Missing Reference: 'RFC4717' is mentioned on line 95, but not defined == Missing Reference: 'RFC4842' is mentioned on line 95, but not defined == Missing Reference: 'CIR' is mentioned on line 259, but not defined == Missing Reference: 'PIR' is mentioned on line 259, but not defined == Unused Reference: 'RFC3916' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'RFC4446' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC4385' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'RFC4623' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'BCP14' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'RFC3821' is defined on line 1248, but no explicit reference was found in the text == Unused Reference: 'RFC2581' is defined on line 1254, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-encap' ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 3916 ** Obsolete normative reference: RFC 4447 (ref. 'RFC4446') (Obsoleted by RFC 8077) -- Duplicate reference: RFC4447, mentioned in 'RFC4447', was also mentioned in 'RFC4446'. ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-BB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-SW' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Obsolete informational reference (is this intentional?): RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Moran Roth (Ed.) 2 Internet-Draft Ronen Solomon 3 Intended status: Standards Track Corrigent Systems 4 Expires: July 15, 2009 Munefumi Tsurusawa 5 KDDI 7 January 15, 2009 9 Reliable Fibre Channel Transport Over MPLS Networks 10 draft-ietf-pwe3-fc-flow-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 15, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames 50 over an MPLS network. This enables service providers to offer 51 "emulated" Fibre Channel services over existing MPLS networks. This 52 document specifies the mechanisms controlling the reliable transport 53 of Fibre Channel PW over MPLS networks. The encapsulation of Fibre 54 Channel PDUs within a pseudowire and the procedures for using a PW to 55 provide a Fibre Channel service are specified in [FC-encap]. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [1]. 63 Table of Contents 65 1. Introduction...................................................4 66 2. Congestion Control.............................................4 67 2.1. Rate Control..............................................5 68 2.1.1. Protocol Mechanism......................................5 69 2.1.2. Data Sender Protocol....................................6 70 2.1.3. Data Receiver Protocol..................................8 71 2.2. Selective Retransmission overview.........................8 72 2.2.1. FC Encapsulation Header................................10 73 2.2.2. Encapsulation Header field parameters..................12 74 2.2.3. Selective reject (SR-SREJ) frame.......................13 75 2.2.4. Exception condition reporting and recovery.............14 76 2.3. Selective Retransmission procedures......................16 77 2.3.1. SR mode of operation...................................16 78 2.3.2. SR procedure for addressing............................16 79 2.3.3. SR procedure for the use of the Poll/Final bit.........16 80 2.3.4. Procedures for information transfer....................17 81 2.3.5. List of SR system parameters...........................24 82 3. Timing Consideration..........................................26 83 4. Applicability Statement.......................................28 84 5. Normative References..........................................28 85 6. Informative references........................................29 86 7. Author's Addresses............................................29 87 8. Contributing Author Information...............................30 89 1. Introduction 91 As metro transport networks migrate towards a packet-oriented network 92 infrastructure, the PSN is being extended in order to allow all 93 services to be transported over a common network infrastructure. This 94 has been accomplished for services such as Ethernet [RFC4448], Frame 95 Relay [RFC4619], ATM [RFC4717] and SONET/SDH [RFC4842] services. 96 Another such service, which has yet to be addressed, is the transport 97 of Fibre Channel (FC) frames over the PSN. This will allow network 98 service providers to transparently carry FC services over the packet- 99 oriented network, along with the aforementioned data and TDM 100 services. 102 FC frames encapsulation within PW PDUs and the procedures for using a 103 PW to provide a Fibre Channel service are specified in a companion 104 document [FC-encap]. However, complementary mechanisms are required 105 to provide reliable FC transport between FC entities. 107 This document specifies the mechanisms to provide reliable transport 108 for FC traffic over MPLS networks, specifically, two mechanisms are 109 specified: 111 (1) Congestion avoidance: this mechanism is intended to alleviate 112 congestion conditions. In order to provide TCP-friendly 113 operation the transmission rate is controlled by the 114 throughput equation specified in [RFC3448]. 116 (2) Selective Retransmission: this mechanism enable lossless 117 transmission of FC frames by retransmission of PW PDUs that 118 were discarded in transit in order to provide lossless 119 transmission for the FC service. A selective retransmission 120 mechanism is specified. 122 2. Congestion Control 124 FC PW traffic can be transmitted over networks that may experience 125 congestion due to statistical multiplexing. When congestion 126 conditions are experienced frames may be discarded within the MPLS 127 PSN. Congestion control mechanism is required to prevent congestion 128 collapse and provide fairness among the different connections. 129 Fairness is usually defined with respect to TCP flow control 130 [RFC2914]. The FC PW relies on a congestion control mechanism that 131 provides TCP-friendly behavior by controlling the transmission rate 132 into the PSN by a rate shaper, whose output rate is a function of 133 network congestion. 135 Frame loss within the MPLS PSN also requires a reliable transmission 136 mechanism in the PE to support faithful emulation of FC service, 137 providing in-order, no-loss transport of FC traffic between CE1 and 138 CE2. Reliable transmission is provided by a sliding-window selective 139 retransmission (SR) mechanism to allow efficient retransmission of 140 lost frames. This was standardized for FC transport in [FC-BB]. The 141 SR mechanism also provides congestion indication (i.e. Frame loss 142 events) to the rate control mechanism. 144 2.1. Rate Control 146 The rate control mechanism provides adaptive shaper control in 147 response to network congestion indications. The rate shaper is 148 configured with BW attributes, such as CIR and EIR, assigned to the 149 FC PW service. The rate control operation is based on [RFC3448]. In 150 the following sections the applicability of [RFC3448] to FC PW is 151 analyzed, and rate control operation is detailed. 153 [RFC3448] is a receiver-based congestion control mechanism, where the 154 congestion control information (i.e., the loss event rate) is 155 calculated by the receiver. In FC PW, on the other hand, the 156 congestion control information is calculated by the sender. This 157 approach is more appropriate for the point-to-point nature of FC PW. 158 This sender-based approach is also mentioned in [RFC3448] as a 159 possible variant of the protocol. 161 2.1.1. Protocol Mechanism 163 In accordance with [RFC3448] the actual allowed sending rate is 164 directly computed by a throughput equation, as a function of lost 165 frames and round trip time. In general, the congestion control 166 mechanism works as follows: 168 o The receiver detects lost frames and feeds this information 169 back to the sender as part of the SR mechanism. 171 o The sender calculates the frame loss probability and measures 172 the round-trip time (RTT) as defined in [FC-BB]. 174 o The lost frame probability and RTT are then fed into the 175 throughput equation, calculating the acceptable transmission 176 rate. 178 o The sender then adjusts its transmission rate to match the 179 calculated rate in accordance with the service BW attributes 180 (CIR, EIR). 182 As the CIR is guaranteed, the throughput equation controls only the 183 excess transmission rate. The parameters of the throughput equation 184 are set as follows: 186 o The retransmission timeout (t_RTO) is replaced by the T1 timer 187 of the SR mechanism as defined in section 6.3. 189 o The number of frames acknowledged by a single SR acknowledgment 190 frame (b) is set to b = 1, as recommended in [RFC3448]. 191 Different implementation MAY use delayed acknowledgement by 192 increasing the value of b. 194 Frame loss probability (p) and RTT (R) are calculated as specified in 195 Section 6.1.2. 197 2.1.2. Data Sender Protocol 199 The data sender sends a stream of data frames to the data receiver at 200 a controlled rate. When a feedback frame is received from the data 201 receiver, the data sender calculates the frame loss probability and 202 changes its sending rate accordingly. If the sender does not receive 203 a feedback frame during a timeout period, it reduces its sending 204 rate. This is achieved by the SR T1 timer. 206 We specify the sender-side protocol in the following steps: 208 o Sender initialization. 210 o The sender behavior when a feedback frame is received. 212 o The sender calculation of the frame loss probability. 214 o The sender behavior when a feedback frame is not received for 215 a timeout period. 217 The sender rate shaper is initialized to transmit at the CIR. The SR 218 mechanism is also initialized by resetting the sequence numbers. 220 The sender calculates RTT (R), based on delay measurement frames 221 transmitted by the NSP (as defined in [FC-BB]). These frames MUST be 222 sent at least every 100 milliseconds, and are used to measure round 223 trip samples that are averaged to obtain RTT (refer to [RFC3448] 224 section 4.3 for details). If an RTT measurement is missed (either due 225 to a loss of a delay measurement frame, or to an RTT larger than the 226 measurement period), PE1 SHOULD shut the PW down, as specified in 227 [FC-BB]. 229 The sender calculates the frame loss probability based on feedback 230 frames generated by the receiver. A feedback frame with accordance to 231 the SR mechanism defined in [FC-BB] is one of the following: 233 o Receiver Ready (RR) - a frame that includes the N(R) counter to 234 acknowledge the sender frames up to frame N(R). 236 o Receiver Not Ready (RNR) - a frame that includes the N(R) 237 counter to acknowledge the sender frames up to frame N(R), and 238 pause the sender from sending additional frames. 240 o Selective Reject (SREJ) - a frame that includes lost frames 241 indication (sequence numbers). 243 When the sender receives a feedback frame it re-calculates the frame 244 loss probability. RR and RNR will effectively decrease the frame loss 245 probability due to no frame loss. On the other hand, reception of a 246 SREJ frame tends to increase the frame loss probability. An 247 implementation MAY consider sending feedback frames, in a controlled 248 network environment, with expedite forwarding (EF) CoS to assure 249 delivery. 251 After the frame loss probability is updated, the sender calculates a 252 new transmission rate for the rate shaper. The transmission rate is 253 calculated as: Rate = MIN( PIR, MAX(CIR,X) ), where CIR is the 254 Committed Information Rate, PIR is the Peak Information Rate (PIR = 255 CIR+EIR), X is the outcome of the throughput equation as specified in 256 [RFC3448], and MIN/MAX are functions returning the smallest/largest 257 value among their operands, respectively. Note that the transmission 258 rate as controlled by the above function, is bounded in the range 259 [CIR,PIR]. 261 No feedback in accordance with [RFC3448] is defined by the timer T1. 262 When the sender does not receive a feedback for such an interval it 263 halves its transmission rate as defined in [RFC3448]. The 264 transmission rate equation as specified above MUST still be applied 265 to guarantee that the CIR is the lower limit for the throughput. The 266 procedure controlling timer T1 (refer to Section 6.3) guarantees that 267 transmission rate is not halved during idle periods, as the timer is 268 not activated during these periods. 270 The maximum burst size allowed MUST be limited to a round-trip time's 271 worth of packets, to achieve efficient transmission while conforming 272 to [RFC3448]. 274 In case the transmission rate is equal to CIR for a period greater 275 than RTT, and transmitted frames are still lost in transit, as 276 indicated to the sender by receiving SREJ frames, the sender MUST 277 signal PW status of "Unable to maintain minimum transmission rate" 278 (refer to Section 9 - "IANA Considerations" for details) as specified 279 in [RFC4447], and MUST stop transmission over the PW for a duration 280 of 10 seconds (this period allows a transient network problem to 281 resolve itself, and guarantees that no more than one HELLO message 282 [FC-SW] is lost, and the link between the two FC devices is not 283 affected). The sender and receiver MUST discard all frames residing 284 in the buffers associated with the congested PW. The sender MUST also 285 discard all frames received from the attached FC device. If within 10 286 seconds after transmission was restarted severe congestion conditions 287 are encountered, as described above (i.e., CIR cannot be maintained), 288 the sender MUST shut the PW down, as described in Section 6.5 of 289 [RFC3985]. If the PW has been set up using the PWE3 control protocol 290 [RFC4447], the regular PW teardown procedures SHOULD be used. The PW 291 MUST NOT be automatically restarted, and administrative intervention 292 is required. Upon PW shutdown the sender and receiver MUST discard 293 all frames associated with the PW. Note that congestion may be 294 avoided by employing connection admission control (CAC) mechanism, 295 which assures that congestion conditions will not be reached when a 296 PW is transmitting at its configured CIR. 298 2.1.3. Data Receiver Protocol 300 The data receiver receives a stream of data frames from the data 301 sender, generates SR feedback frames (SR-RR, SR-RNR and SR-SREJ), and 302 sends them to the data sender. The details of feedback frames 303 generation and transmission are specified in section 6.3. 305 2.2. Selective Retransmission overview 307 The selective retransmission mechanism provides efficient 308 retransmission of lost frames to enable faithful emulation of FC 309 service, with no frame loss experienced by the CE. The proposed 310 selective retransmission mechanism was standardized for FC transport 311 in [FC-BB], and is specified in details in this standard. 313 The SR protocol is an efficient sliding window full-duplex protocol 314 that supports both the flow control and error recovery functions. SR 315 has been adopted from ITU's Link Access Protocol B (LAPB) that was 316 derived from ISO/IEC's High-level Data Link Control (HDLC) balanced 317 classes. Use of LAPB in SR is limited to a subset of the synchronous 318 modulo 32768 super sequence numbering service option. 320 SR works between two PE devices (see figure 7). SR flow control works 321 by streaming multiple messages within an allowed window, bounded by 322 the system parameter k, and awaits acknowledgements before sending 323 more messages. Acknowledgements indicate which messages were 324 correctly received and there is a provision for requesting 325 retransmission of selected messages in the current window. Fibre 326 Channel Sequences and Exchanges are not visible to the SR flow 327 control protocol which sees the PW packets constructed from the FC 328 frames. 330 Some benefits of the SR protocol are summarized below: 332 a) it is used for reliable transport of all Class 2, 3, 4, and F 333 frames between two PE devices; 335 b) it optimizes buffer management at the PE devices; 337 c) it acts as a congestion avoidance technique to match the capacity 338 of the sender to the capacity of the network that carries the 339 payload; 341 d) it ensures correct delivery of messages (i.e., an error control 342 and recovery function); and 344 e) it provides a continuous stream of traffic across the MPLS 345 PSN thus leading to a higher throughput (i.e., optimizes bandwidth 346 utilization at each BBW device). 348 Note that the synchronization of the Sender PE and the Receiver PE at 349 the PW message level, which is required for correct SR operation is 350 performed through PW signaling. 352 The four different SR messages described in section 6.2.1 have a 353 correspondence to the LAPB frame types. Note that only the 354 information transfer SR-I message is flow-controlled while all other 355 messages are control messages of the protocol. 356 The SR protocol specifies the maximum number (k) of outstanding 357 messages at any given time. k is a system parameter that is not 358 negotiated and is fixed in a given implementation. The value of this 359 system parameter depends on the MPLS PSN delay characteristics and 360 the number of buffers available. Typically, the value of k is 361 expected to be far below the maximum number of 32767. 363 +--------------------+ +--------------------+ 364 | PE | | PE | 365 | | | | 366 | +--------------+ | | +--------------+ | 367 | | Flow Control |<---------------->| Flow Control | | 368 | | Protocol | | | | Protocol | | 369 | +--------------+ | | +--------------+ | 370 | | | | | | 371 | | | | | | 372 | +--------------+ | | +--------------+ | 373 | | PW Interface | | | | PW Interface | | 374 | +--------------+ | | +--------------+ | 375 | | | | 376 +--------------------+ +--------------------+ 377 | - -- | 378 | -- / \ / \ | 379 | / \/ -- \ | 380 | \ / | 381 | \ MPLS \ | 382 +---------/ PSN /-----------+ 383 / / 384 ------------- 386 Figure 7 - SR flow control protocol between two PEs 388 2.2.1. FC Encapsulation Header 390 The FC Encapsulation Header defines two types of field formats that 391 are used to perform information transfer (i.e., I-format frames), and 392 supervisory functions (i.e., S-format frames). SR makes use of four 393 different types of messages: 395 a) I-format (1): SR-I frame. 397 This frame is used to perform an information transfer. The 398 Encapsulation Header of an I-format frame is shown in figure 8. 399 The I-frame Encapsulation Header contains the following fields: 400 (1) N(S): Transmitter send sequence number. 401 (2) N(R): Transmitter receive sequence number. 402 (3) P: Poll bit (1 = Poll). 404 A detailed description of the different fields and explanation of 405 The functionality involved is provided in section 6.2.2. 407 An SR-I frame is a command message (i.e., the A-bit in the Control 408 Word is set to 1), and carries an encapsulated FC frame. 410 b) S-format (3): SR-RR, SR-RNR, SR-SREJ frames. 412 These frames are used to perform supervisory control functions of 413 the Selective Retransmission mechanism, such as acknowledge SR-I 414 messages, request retransmission of SR-I messages, and to request 415 a temporary suspension of transmission of SR-I messages. The 416 Encapsulation Header of an S-format frame is shown in figure 9. 418 The S-frame Encapsulation Header contains the following fields: 420 (1) N(R): Transmitter receive sequence number. 422 (2) S: Supervisory function bits to define the frame type. 423 S = 00: SR-RR. 424 S = 01: Reserved. 425 S = 10: SR-RNR. 426 S = 11: SR-SREJ. 428 (3) P: Poll/Final bit (refer to section 6.2.2 for detailed 429 description). 431 (4) Reserved: MUST be set to 0 by the ingress PE, and MUST be 432 ignored by the egress PE. 434 A detailed description of the different fields and explanation of 435 The functionality involved is provided in section 6.2.2. 437 An SR-RR frame carries no payload, and may be either a command or 438 response message (the A-bit in the Control Word is set to 1 for a 439 Command, and to 0 for a Response). It indicates Ready to Receive 440 SR-I messages (negates busy condition) and acknowledges previous 441 SR-I messages. 443 An SR-RNR frame carries no payload, and may be either a command or 444 response message. It indicates Receiver not Ready to accept more 445 SR-I messages (busy condition) and acknowledges previous SR-I 446 messages. 448 An SR-SREJ frame may be either a command or response message, and 449 carries a payload that indicate SR-I frames in need of selective 450 retransmission. 452 1 2 3 453 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 454 +-+-----------------------------+-+-----------------------------+ 455 |0| N(S) |P| N(R) | 456 +-+-----------------------------+-+-----------------------------+ 458 Figure 8 - FC Encapsulation Header format for I-frame 460 1 2 3 461 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 462 +-+-+---+-----------------------+-+-----------------------------+ 463 |1|0| S | Reserved |P| N(R) | 464 +-+-+---+-----------------------+-+-----------------------------+ 466 Figure 9 - FC Encapsulation Header format for S-frame 468 2.2.2. Encapsulation Header field parameters 470 The following describes the different fields of the Encapsulation 471 Header and details how these fields are handled. 473 a) Modulus of SR - Each SR-I message is sequentially numbered and may 474 have the value 0 through modulus minus 1, where "modulus" is equal 475 to 32768 (i.e., the maximum value of the sequence numbers). The 476 sequence numbers cycle through the entire range. 478 b) Send state variable V(S) - The send state variable V(S) denotes 479 the sequence number of the next-in-sequence SR-I message to be 480 transmitted. V(S) may take on the values 0 through modulus minus 481 1. The value of V(S) is incremented by 1 with each successive SR-I 482 message transmission, but cannot exceed the N(R) of the last 483 received SR-I or supervisory message by more than the maximum 484 number of outstanding SR-I messages k. The value of k is defined 485 in section 6.3.5. 487 c) Send sequence number N(S) - Only SR-I messages contain N(S), the 488 send sequence number of the transmitted SR-I message. At the time 489 that an in-sequence SR_I message is designated for transmission, 490 the value of N(S) is set to the value of the send state variable 491 V(S). 493 d) Receive state variable V(R) - The receive state variable V(R) 494 denotes the sequence number of the next-in-sequence SR-I message 495 expected to be received. V(R) may take on the values 0 through 496 modulus minus 1. The value of V(R) is incremented by 1 by the 497 receipt of an error-free, in-sequence SR-I message whose send 498 sequence number N(S) equals the receive state variable V(R). 500 e) Rceive sequence number N(R) - All SR-I messages and supervisory 501 messages, except SR-SREJ messages with the F bit set to 0, SHALL 502 contain N(R), the expected send sequence number of the next 503 received SR-I message. At the time that a message of the above 504 types is designated for transmission, the value of N(R) is set to 505 the current value of the receive state variable V(R). N(R) 506 indicates that the PE transmitting the N(R) has correctly received 507 all SR_I messages numbered up to and including N(R)-1. 509 f) Functions of the Poll/Final bit (P-bit) - All messages contain P- 510 bit, the Poll/Final bit. In command messages, the P-bit is 511 referred to as the Poll bit. In response messages it is referred 512 to as the Final bit. 514 The Poll bit set to 1 is used by the PE to solicit (i.e., poll) a 515 response from the remote PE. 517 The Final bit set to 1 is used by the PE to indicate the response 518 message transmitted by the remote PE, as a result of the 519 soliciting (i.e., poll) command. 520 The use of the P/F bit is further described in section 6.3.3. 522 2.2.3. Selective reject (SR-SREJ) frame 524 The SR-SREJ supervisory message is used by a PE to request 525 retransmission of one or more, not necessarily contiguous, SR-I 526 messages. The N(R) field SHALL contain the sequence number of the 527 earliest SR-I message to be retransmitted and the information field 528 (see figure 9) SHALL contain, in ascending order (i.e., 32767 is 529 higher than 32766 and 0 is higher than 32767 for modulo 32768), the 530 sequence numbers of additional SR-I message(s), if any, that needs to 531 be retransmitted. 533 The payload field SHALL be encoded such that there is a 2-byte field 534 for each standalone SR-I message in need of retransmission, and a 4- 535 byte span list for each sequence of two or more contiguously numbered 536 SR-I messages in need of retransmission, as depicted in figure 9. 537 Standalone SR-I messages are identified in the payload field by the 538 appropriate N(R) value preceded by a 0 bit in the 2-byte field used. 539 Span lists are identified in the payload field by the N(R) value of 540 the first SR-I message in the span list preceded by a 1 bit in the 2- 541 byte field used, followed by the N(R) value of the last message in 542 the span list preceded by a 1 bit in the 2-byte field used. 544 The maximum payload size of a SR-SREJ message is 2148 bytes 545 corresponding to a maximum possible encoding of 1074 standalone SR-I 546 messages or a maximum possible encoding of 537 span list sets. 547 If the P-bit in an SR-SREJ message is set to 1, then SR-I messages 548 numbered up to N(R)-1 inclusive, N(R) being the value in the 549 Encapsulation Header field, shall be considered as acknowledged. If 550 the P-bit in an SR-SREJ message is set to 0, then the N(R) in the 551 Encapsulation Header field of the SR-SREJ message does not indicate 552 acknowledgement of SR-I messages. 554 1 2 3 555 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 556 +---------------------------------------------------------------+ 557 | FC PW Control Word | 558 +---------------------------------------------------------------+ 559 | FC Encapsulation Header | 560 +-+-----------------------------+-+-----------------------------+ 561 |0| N(R) of standalone SR-I |1| N(R) of first SR-I in span | 562 +-+-----------------------------+-+-----------------------------+ 563 |1| N(R) of last SR-I in span |0| N(R) of standalone SR-I | 564 +-+-----------------------------+-+-----------------------------+ 565 |1| N(R) of first SR-I in span |1| N(R) of last SR-I in span | 566 +-+-----------------------------+-+-----------------------------+ 567 | | 568 . . 569 . . 570 +---------------------------------------------------------------+ 572 Figure 10 - SR-SREJ frame format example 574 2.2.4. Exception condition reporting and recovery 576 The error recovery procedures that are available to effect recovery 577 following the detection/occurrence of an exception condition are 578 described in this section. Exception conditions described are those 579 situations that may occur as the result of transmission errors, PE 580 device malfunction, or operational situations. 582 a) Busy condition - The busy condition results when the PE is 583 temporarily unable to continue to receive SR-I messages due to 584 internal constraints (e.g., receive buffering limitations). Upon 585 entering the busy condition, a PE transmits an SR-RNR message. 586 SR-I messages pending transmission may be transmitted from the 587 busy PE prior to or following the SR-RNR message. 588 An indication that the busy condition has cleared is communicated 589 by the transmission of SR-RR or SR-SREJ. 591 b) N(S) sequence error condition - The information field of all 592 received SR-I messages whose N(S) is not in the range V(R) and 593 V(R)+k-1 inclusive, SHALL be discarded. The information field of 594 all SR-I messages received by the PE whose N(S) is in the range 595 V(R) and V(R) + k -1 inclusive, SHALL be saved in the receive 596 buffer. 598 An N(S) sequence error exception condition occurs in the receiver 599 when a received SR-I message contains an N(S) that is not equal to 600 the receive state variable V(R) at the receiver. The receiver 601 SHALL not acknowledge (i.e., increment its receive state variable) 602 the SR-I message causing the sequence error, or any SR-I message 603 that may follow, until an SR-I message with the correct N(S) is 604 received. 606 A PE that receives one or more valid SR-I messages having sequence 607 errors or subsequent supervisory messages (i.e., SR-RR, SR-RNR, or 608 SR-SREJ) shall accept and handle the N(R) field and the P-bit. 610 The means specified below shall be available for initiating the 611 retransmission of lost or errored SR-I messages following the 612 occurrence of an N(S) sequence error condition. 614 (1) SR-SREJ recovery - The SR-SREJ message shall be used to 615 initiate more efficient error recovery by selectively 616 requesting the retransmission of one or more, not necessarily 617 contiguous, lost or errored SR-I message(s) following the 618 detection of sequence errors, rather than requesting the 619 retransmission of all SR-I messages. 621 When a PE receives an out-of-sequence message, the SR-I 622 message shall be saved in a receive buffer. The SR-I message 623 shall be delivered to the upper layer only when all SR-I 624 messages numbered below N(S) are correctly received. If 625 message number N(S)-1 has not been received previously, then 626 an SR-SREJ response message with the P-bit set to 0 shall be 627 transmitted containing the sequence numbers of the block of 628 consecutive missing SR-I messages ending at N(S)-1. On 629 receiving such an SR-SREJ message the PE shall retransmit all 630 requested SR-I messages. After retransmitting these SR-I 631 messages, the BBW may transmit new SR_I messages, if they 632 become available. 634 When a PE receives a command message with the P-bit set to 1, 635 if there are out-of-sequence SR-I messages saved in the 636 receive buffer, it shall transmit an SR-SREJ message, with the 637 F bit set to 1, containing a complete list of missing sequence 638 numbers. The PE that receives the SR-SREJ message shall 639 retransmit all requested SR-I messages, except those that were 640 transmitted subsequent to the last command message with the P 641 bit set to 1. 643 (2) Time-out recovery - If a PE, due to a transmission error, does 644 not receive, or receives and discards, a single SR-I message 645 or the last SR-I message in a sequence of SR-I messages, it 646 shall not detect a N(S) sequence error condition and, 647 therefore, shall not transmit an SR-SREJ message. 649 The PE that transmitted the unacknowledged SR-I message(s) 650 shall, following the completion of a system specified time-out 651 period (see section 6.3.4 items b) and j) below), send a 652 supervisory command message (i.e., SR-RR or SR-RNR) with the 653 P-bit set to 1. SR-I messages shall be retransmitted on the 654 receipt of an SR-RR response message with the F bit set to 1 655 or an SR-SREJ message. 657 c) Invalid message condition - Any message that is invalid shall be 658 discarded, and no action is taken as the result of that message. 659 An invalid message is defined as one that contains: 661 (1) the Control Word with an invalid encoding; or 663 (2) the Encapsulation Header with an invalid encoding. 665 2.3. Selective Retransmission procedures 667 2.3.1. SR mode of operation 669 The SR protocol shall be limited to a subset of the synchronous 670 modulo 32768 super sequence numbering service option operation of the 671 LAPB protocol. The SR protocol is initialized upon PW set-up 672 following a successful signaling session. 674 2.3.2. SR procedure for addressing 676 The Address Bit field in the Control Word (see figure 3) identifies a 677 message as either a command or a response. This field is used in 678 conjunction with the P-bit (Poll/Final). 680 2.3.3. SR procedure for the use of the Poll/Final bit 681 The PE receiving a supervisory command (i.e., SR-RR, SR-RNR, SR- 682 SREJ), or SR-I message with the P bit set to 1 shall set the F bit to 683 1 in the next response message it transmits. 685 The response message returned by the PE to an SR-I message with the P 686 bit set to 1, shall be an SR-RR, SR-SREJ, or SR-RNR response with the 687 F bit set to 1. 689 The response message returned by the PE to a supervisory command with 690 the P bit set to 1, shall be an SR-RR, SR-RNR, or SR-SREJ response 691 with the F bit set to 1. 693 The P bit may be used by the PE in conjunction with the timer 694 recovery condition (see section 6.3.4. item j) below). 696 2.3.4. Procedures for information transfer 698 a) Procedures for SR-I messages 700 The procedures that apply to the transmission of SR-I messages in 701 each direction using multi-selective reject are described below. 703 b) Sending new SR-I messages 705 When the PE has a new SR-I message to transmit (i.e., an SR-I message 706 not already transmitted), it shall transmit it with a N(S) equal to 707 its current send state variable V(S), and a N(R) equal to its current 708 receive state variable V(R). At the end of the transmission of the 709 SR-I message, it shall increment its send state variable V(S) by 1. 711 If the SR timer T1 is not running at the time of transmission of the 712 SR-I message, it shall be started. 714 If the SR send state variable V(S) is equal to the last value N(R) 715 received plus k, where k is the maximum number of outstanding SR-I 716 frames (see section 6.3.5), the PE shall not transmit any new SR-I 717 frames. 719 If the remote PE is busy, the PE shall not transmit any new SR-I 720 messages. 722 When the PE is in the busy condition, it may still transmit SR-I 723 messages, provided that the remote PE is not busy. 725 c) Receiving an in-sequence SR-I message 726 When the PE is not in a busy condition and receives a valid SR-I 727 message whose send sequence number N(S) is equal to its receive state 728 variable V(R), the PE shall accept the information field of this 729 message and increment by one the receive state variable V(R). If the 730 SR-I message, whose N(S) is equal to the incremented value of V(R), 731 is present in the receive buffer, then the PE shall remove it from 732 the receive buffer, deliver it to the upper layer and increment V(R) 733 by one. The PE shall repeat this procedure until V(R) reaches a value 734 such that the SR-I message whose N(S) is equal to V(R) is not present 735 in the receive buffer. The PE shall then take one of the following 736 actions: 738 (1) if the PE is now in the busy condition, it shall transmit an 739 SR-RNR message with N(R) equal to the value of the SR receive 740 variable V(R) (see item i) below); or 742 (2) if the PE is still not in a busy condition: 744 - if the P bit is set to 1, then the PE shall transmit a 745 response message with the F bit set to 1, as specified in 746 item l) below; 748 - if an SR-I message is available for transmission the PE 749 shall act as described in item b) above, sending new SR-I 750 messages and acknowledging the received SR-I message by 751 setting N(R) in the Encapsulation Header field of the next 752 transmitted SR-I message to the value of the SR receive 753 state variable V(R), or the PE shall acknowledge the 754 received SR-I message by transmitting an SR-RR message 755 with the N(R) equal to the value of the SR receive state 756 variable V(R); or 758 - the PE shall transmit an SR-RR message with N(R) equal to 759 the value of the SR receive state variable V(R). 761 When the PE is in a busy condition, it may ignore the information 762 field contained in any received SR-I message. 764 d) Reception of invalid messages 766 When the PE receives an invalid message (see 6.2.4. item c), it shall 767 discard the message. 769 e) Reception of out-of-sequence SR-I messages 771 When the PE is not in a busy condition and it receives a valid SR-I 772 message whose send sequence number N(S) is out-of-sequence, (i.e., 773 not equal to the receive state variable V(R)), then it shall perform 774 one of the following actions: 776 1) if N(S) is less than V(R) or greater than or equal to V(R) + k, 777 then it shall discard the information field of the SR-I 778 message. If the P bit of the SR-I message is set to 1, then the 779 PE shall transmit a response message with the F bit set to 1, 780 as specified in item l) below; or 782 2) if N(S) is greater than V(R) and less than V(R) + k, then it 783 shall save the SR-I message in the receive buffer. It shall 784 then perform one of the following actions: 786 - if the P bit of the SR-I message is set to 1, then the PE 787 shall transmit a response message with the F bit set to 1, 788 as specified in item l) below; 790 - if the PE is now in a busy condition, it shall transmit an 791 SR-RNR message with N(R) equal to the value of the receive 792 variable V(R), as specified in item i) below; or 794 - if the SR-I message numbered N(S)-1 has not yet been 795 received, then the PE shall transmit an SR-SREJ response 796 message with the F bit set to 0. The PE shall create a list 797 of contiguous sequence numbers N(X), N(X)+1, N(X)+2,..., 798 N(S)-1, where N(X) is greater than or equal to V(R) and 799 none of the SR-I messages N(X) to N(S)-1 have been 800 received. The N(R) field of the SR-SREJ message shall be 801 set to N(X) and the information field set to the list 802 N(X)+1,...,N(S)-1. If the list of sequence numbers is too 803 large to fit into the information field of the SR-SREJ 804 message, then the list shall be truncated to fit in one 805 SR-SREJ message, by including only the earliest sequence 806 numbers. 808 When the PE is in the busy condition, it may ignore the information 809 field contained in any received SR-I message. 811 f) Receiving acknowledgement 813 When correctly receiving an SR-I message or a supervisory message 814 (i.e., SR-RR, SR-RNR, or SR-SREJ with the F bit set to 1), even in 815 the busy condition, the PE shall consider the N(R) contained in this 816 message as an acknowledgement for all the SR-I messages it has 817 transmitted with a N(S) up to and including the received N(R)-1. The 818 PE shall stop the timer T1 if the received supervisory message has 819 the F bit set to 1 or if there is no outstanding poll condition and 820 the N(R) is higher than the last received N(R), actually 821 acknowledging some SR-I messages. 823 If timer T1 has been stopped by the receipt of an SR-I message, an 824 SR-RR command message, an SR-RR response message with the F bit set 825 to 0, or an SR-RNR message, and if there are outstanding SR-I 826 messages still unacknowledged, the PE shall restart timer T1. If 827 timer T1 has been stopped by the receipt of an SR-SREJ message with 828 the F bit set to 1, the PE shall follow the retransmission procedure 829 specified in item g.2) below. If timer T1 has been stopped by the 830 receipt of an SR-RR message with the F bit set to 1, the PE shall 831 follow the retransmission procedure specified in item k) below. 833 g) Receiving an SR-SREJ response message 835 1) Receiving an SR-SREJ response message with the F bit set to 0 837 When receiving an SR-SREJ response message with the F bit set 838 to 0, the PE shall retransmit all SR-I messages, whose sequence 839 numbers are indicated in the N(R) field and the information 840 field of the SR-SREJ message, in the order specified in the 841 SR-SREJ message. Retransmission shall conform to the following: 843 - if the PE is transmitting a supervisory or SR-I message 844 when it receives the SR-SREJ message, it shall complete 845 that transmission before commencing transmission of the 846 requested SR-I messages; or 848 - if the PE is not transmitting any message when it receives 849 the SR-SREJ message, it shall commence transmission of the 850 requested SR-I messages immediately. 852 If there is no outstanding poll condition, then a poll shall be 853 sent, either by transmitting an SR-RR command, or SR-RNR 854 command if the PE is in the busy condition, with the P bit set 855 to 1 or by setting the P bit in the last retransmitted SR-I 856 message and timer T1 shall be restarted. 858 If there is an outstanding poll condition, then timer T1 shall 859 not be restarted. 861 2) Receiving an SR-SREJ response message with the F bit set to 1 863 When receiving an SR-SREJ response message with the F bit set 864 to 1, the PE shall retransmit all SR-I messages, whose sequence 865 numbers are indicated in the N(R) field and the information 866 field of the SR-SREJ message, in the order specified in the 867 SR-SREJ message, except those messages that were sent after the 868 message with the P bit set to 1 was sent. Retransmission shall 869 conform to the following: 871 - if the PE is transmitting a supervisory message or SR-I 872 message when it receives the SR-SREJ message, it shall 873 complete that transmission before commencing transmission 874 of the requested SR-I messages; or 876 - if the PE is not transmitting any message when it receives 877 the SR-SREJ message, it shall commence transmission of the 878 requested SR-I messages immediately. 880 If any messages are retransmitted, then a poll shall be sent, 881 either by transmitting an SR-RR command, or SR-RNR command if 882 the PE is in the busy condition, with the P bit set to 1 or by 883 setting the P bit in the last retransmitted SR-I message. 885 Timer T1 shall be restarted. 887 h) Receiving an SR-RNR message 889 After receiving an SR-RNR message, the PE shall stop transmission of 890 SR-I messages until an SR-RR or SR-SREJ message is received. 892 The PE shall start timer T1, if necessary, as specified in section 893 6.3.5. 895 When timer T1 runs out before receipt of a busy clearance indication, 896 the PE shall transmit a supervisory message (i.e., SR-RR, SR-RNR), 897 with the P bit set to 1 and shall restart timer T1, in order to 898 determine if there is any change in the receive status of the remote 899 PE. The remote PE shall respond to the P bit set to 1 with a 900 supervisory response message (i.e., SR-RR, SR-RNR, SR-SREJ) with the 901 F bit set to 1 indicating continuation of the busy condition (i.e., 902 SR-RNR message) or clearance of the busy condition (i.e., SR-RR, SR- 903 SREJ). Upon receipt of the remote PE response, timer T1 shall be 904 stopped. The PE shall process the supervisory response message as 905 follows: 907 1) if the response is an SR-RR message, the busy condition shall 908 be assumed to be cleared and the PE may retransmit messages as 909 specified in item k) below. New SR-I messages may be 910 transmitted as specified in item b) above; 912 2) if the response is an SR-SREJ message, the busy condition shall 913 be assumed to be cleared and the PE may retransmit messages as 914 specified in item g.2) above. New SR-I messages may be 915 transmitted as specified in item b) above; or 917 3) if the response is an SR-RNR message, the busy condition shall 918 be assumed to still exist and the PE, after a period of time 919 (e.g., the duration of timer T1), shall repeat the enquiry of 920 the remote PE receive status. 922 If timer T1 runs out before a status response is received, the 923 enquiry process above shall be repeated. If N2 attempts to get a 924 status response fail, the PE MAY declare the PW as down. 926 If, at any time during the enquiry process, an unsolicited SR-RR or 927 SR-SREJ message is received from the remote PE, it shall be 928 considered to be an indication of clearance of the busy condition. 929 Should the unsolicited SR-RR message be a command message with the P 930 bit set to 1, the appropriate response message with the F bit set to 931 1 shall be transmitted (see item l) below) before the PE may resume 932 transmission of SR-I messages. The PE shall not clear the outstanding 933 poll condition. The PE shall not stop timer T1. If an unsolicited SR- 934 SREJ message is received, then the PE shall perform retransmissions 935 as specified in item g.1) above. 937 i) BBW busy condition 939 When the PE enters a busy condition, it shall transmit an SR-RNR 940 message at the earliest opportunity. The SR-RNR message shall be a 941 command frame with the P bit set to 1 if an acknowledged transfer of 942 the busy condition indication is required, otherwise the SR-RNR 943 message may be a command or response message. While in the busy 944 condition, the PE shall accept and process supervisory messages, 945 accept and process the N(R) field of SR-I, SR-RR, and SR-SREJ 946 messages with the F bit set to 1, and return an SR-RNR response with 947 the F bit set to 1 if it receives a supervisory command or SR-I 948 command message with the P bit set to 1. Received SR-I messages may 949 be discarded or saved as specified in items c) and e) above, however, 950 SR-RR or SR-SREJ messages shall not be transmitted. To clear the busy 951 condition, the PE shall transmit an SR-RR message, with the N(R) 952 field set to the current receive state variable V(R). The SR-RR 953 message shall be a command message with the P bit set to 1 if an 954 acknowledged transfer of the busy-to-non-busy transition is required, 955 otherwise the SR-RR message may be either a command or response 956 message. 958 j) Awaiting acknowledgement 959 If the timer T1 runs out while waiting for the acknowledgement of an 960 SR-I message from the remote PE, the PE shall restart timer T1 and 961 transmit an appropriate supervisory command message (i.e., SR-RR, SR- 962 RNR) with the P bit set to 1. The PE may transmit new SR-I messages 963 after sending this enquiry message. 965 If the PE receives an SR-SREJ response message with the F bit set to 966 1, the PE shall restart timer T1 and retransmit SR-I messages as 967 specified in item g.2) above. 969 If the PE receives an SR-SREJ response message with the F bit set to 970 0, the PE shall retransmit SR-I messages as specified in item g.2) 971 above. 973 If the PE receives an SR-RR response message with the F bit set to 1, 974 the PE shall restart timer T1 and retransmit SR-I messages as 975 specified in item k) below. 977 If the PE receives an SR-RR response message with the F bit set to 0, 978 or an SR-RR command message or SR-I message with the P bit set to 0 979 or 1, the PE shall not restart timer T1, but shall use the received 980 N(R) as an indication of acknowledgement of transmitted SR-I messages 981 up to and including SR-I message numbered N(R)-1. 983 If timer T1 runs out before a supervisory response message with the F 984 bit set to 1 is received, the PE shall retransmit an appropriate 985 supervisory command message (i.e., SR-RR, SR-RNR) with the P bit set 986 to 1. After N2 such attempts, the PE MAY declare the PW as down. 988 k) Receiving an SR-RR response messages with the F bit set to 1 990 When receiving an SR-RR response message with the F bit set to 1, the 991 PE shall process the N(R) field as specified in item f) above. If 992 there are outstanding SR-I messages that are unacknowledged and no 993 new SR-I messages have been transmitted subsequent to the last 994 message with the P bit set to 1, then the PE shall retransmit all 995 outstanding SR-I messages except those that were sent after the 996 message with the P bit set to 1 was sent. Retransmission shall 997 conform to the following: 999 1) if the PE is transmitting a supervisory or SR-I message when it 1000 receives the SR-RR message, it shall complete that transmission 1001 before commencing transmission of the requested SR-I messages; 1003 2) if the PE is not transmitting any message when it receives the 1004 SR-RR message, it shall commence transmission of the requested 1005 SR-I messages immediately. 1007 If any messages are retransmitted, then a poll shall be sent, either 1008 by transmitting an SR-RR command, or SR-RNR command if the PE is in 1009 the busy condition, with the P bit set to 1 or by setting the P bit 1010 in the last retransmitted SR-I message. 1012 The timer T1 shall be stopped. If any SR-I messages are outstanding, 1013 then timer T1 shall be started. 1015 l) Responding to command messages with the P bit set to 1 1017 When receiving an SR-RR, SR-RNR, or-SR_I command message with the P 1018 bit set to 1, the PE shall generate an appropriate response message 1019 as follows: 1021 1) if the PE is in the busy condition, it shall transmit an SR-RNR 1022 response message with the F bit set to 1; 1024 2) if there are some out-of-sequence messages in the receive 1025 buffer, then it shall transmit an SR-SREJ message with the F 1026 bit set to 1; N(R) shall be set to the receive state variable 1027 V(R) and the information field set to the sequence numbers of 1028 all missing SR-I messages, except V(R). If the list of sequence 1029 numbers is too large to fit in the information field of the 1030 SR-SREJ message, then the list shall be truncated by including 1031 only the earliest sequence numbers; or 1033 3) if there are no out-of-sequence messages in the receive buffer, 1034 then an SR-RR response message with the F bit set to 1 shall be 1035 sent. 1037 2.3.5. List of SR system parameters 1039 a) SR Poll Timeout (Timer T1) 1041 The same value of the timer T1 shall be made known and agreed to by 1042 the two PEs. 1044 The period of timer T1, at the end of which retransmission of a 1045 message may be initiated (see 6.3.4), shall take into account whether 1046 T1 is started at the beginning or the end of the transmission of a 1047 message. 1049 The proper operation of the procedure requires that the transmitter's 1050 timer T1 be greater than the maximum time between transmission of a 1051 message (i.e., SR_I, or supervisory command) and the reception of the 1052 corresponding message returned as an answer to that message (i.e., 1053 acknowledging message). Therefore, the receiver should not delay the 1054 response or acknowledging message returned to one of the above 1055 messages by more than a value T2, where T2 is a system parameter (see 1056 item b) below). 1058 The PE shall not delay the response or acknowledging message returned 1059 to one of the above remote PE messages by more than a period T2. 1061 b) SR Response Timeout (Timer T2) 1063 The same value of the parameter T2 shall be made known and agreed to 1064 by the two PEs. The period of parameter T2 shall indicate the amount 1065 of time available at the PE before the acknowledging message shall be 1066 initiated in order to ensure its receipt by the remote PE, prior to 1067 timer T1 running out at the PEs (parameter T2 < timer T1). 1069 The period of parameter T2 shall take into account the following 1070 timing factors: 1072 1) the transmission time of the acknowledging message; 1074 2) the propagation time over the access link; 1076 3) the stated processing times at the PEs; and 1078 4) the time to complete the transmission of the message(s) in the 1079 PE transmit queue that are neither displaceable nor modifiable 1080 in an orderly manner. 1082 Given a value for timer T1 for the PEs, the value of parameter T2 1083 shall be no larger than T1 minus 2 times the propagation time over 1084 the access data link, minus the message processing time at the PE, 1085 minus the message processing time at the remote PE, and minus the 1086 transmission time of the acknowledging message by the PE. 1088 c) SR Poll Retries (N2) 1090 The same value of the N2 system parameter shall be made known and 1091 agreed to by the two PEs. 1093 The value of N2 shall indicate the maximum number of attempts made by 1094 the PE to complete the successful transmission of a message to the 1095 remote PE. 1097 d) SR Window Size (k) 1098 The same value of the k system parameter shall be made known and 1099 agreed to by the two PEs. 1101 The value of k shall indicate the maximum number of sequentially 1102 numbered SR-I messages that the PEs may have outstanding (i.e., 1103 unacknowledged) at any given time. The value of k shall never exceed 1104 32767 for modulo 32768 operation. 1106 3. Timing Consideration 1108 Correct Fibre Channel information exchange requires that the inherent 1109 latency between CE1 and CE2 (refer to Figure 1) be: 1111 a) no more than one-half of the R_T_TOV (Receiver Transmitter Timeout 1112 Value, default value: 100 milliseconds, defined in [FC-FS]) of the 1113 attached devices for Primitive Sequences; 1115 b) no more than one-half of the E_D_TOV (Error Detect Timeout Value, 1116 default value: 2 seconds, defined in [FC-FS]) of the attached 1117 devices for frames; and 1119 c) within the R_A_TOV (Resource Allocation Timeout Value, default 1120 value: 10 seconds, defined in [FC-FS]) of the attached fabric(s), 1121 if any. 1123 Requirement a) above, controlling the latency associated with FC 1124 Primitive Sequence transport is addressed by [FC-BB], stating that in 1125 case Primitive Sequences are received from the CE or the remote PE, 1126 while the device is unable to forward these Primitive Sequence due to 1127 backpressure indication, it shall flush its respective buffer (PSN- 1128 facing if the Primitive Sequences were received from the CE, CE- 1129 facing if they were received from the remote PE), and shall forward 1130 the Primitive Sequences. 1132 Another case is when there is no specific backpressure indication, 1133 rather Primitive Sequences are being delayed due to retransmission of 1134 dropped frames. In this case also, the PE shall flush its PSN-facing 1135 buffer and shall forward the Primitive Sequences. 1137 Requirements b) and c) above apply to the latency associated with 1138 transporting FC frames, and the system MUST comply with the lower of 1139 the two timeouts. The mechanism controlling this latency is described 1140 below for the PE1 --> PE2 direction. A duplicate mechanism MUST be 1141 used to control the PE2 --> PE1 direction. 1143 PE2 (the receiver) maintain a timer Td, set to the minimum timeout 1144 set by requirements b) and c), with a safety margin to allow a 1145 deviation of the estimated RTT from the actual RTT. PE2 SHOULD set 1146 Td = 0.8 x (0.5 x MIN(E_D_TOV,R_A_TOV) - 2 x RTT), where RTT is an 1147 average value calculated as specified in Section 6.1.2, and the 1148 factor 0.8 provides safety margins for RTT fluctuations. In case the 1149 calculated Td < 2 x RTT for two consecutive calculation periods, the 1150 FC PW MUST be shut down (this avoids getting into conditions where Td 1151 expiration is too frequent). 1153 To guarantee correct operation of this mechanism FC PW SHOULD NOT be 1154 used in environments where the RTT may have high variability, i.e., 1155 environments where the estimated RTT may not be off by more than 5% 1156 of MIN(E_D_TOV,R_A_TOV). If the FC PW is used in an environment where 1157 this limit is exceeded, the safety margins MUST be increased to 1158 encompass twice the expected maximum variability in the RTT. 1160 Upon Td expiration PE2 declares WAN Down as defined in [FC-BB], send 1161 the Not Operational (NOS) Primitive Sequence to CE2, and flush its 1162 buffers. 1164 The timer Td is started when either of the following two conditions 1165 occurs: 1167 a) SR-RNR is sent by PE2 toward PE1, i.e., PE2 indicates 1168 backpressure, and stop PE1 from transmitting; 1170 b) SR-SREJ is sent by PE2 toward PE1, requiring retransmission. 1172 PE2 notes the sequence number (Nx) of the first frame to be received 1173 following the timer initiation (for SR_RNR this will be the next 1174 frame to be transmitted by PE1, i.e., the sequence number of the last 1175 frame received by PE2 before starting the timer plus 1. For SR_SREJ 1176 this frame will be the first sequence number in the retransmission 1177 list). 1179 The timer continues counting and is initialized in one of two cases: 1181 a) PE2 receives the frame with sequence number (Nx + k), where k is 1182 the Selective Retransmission window size; 1184 b) PE2 identifies idle period (all sent frames were acknowledged, and 1185 the CE-facing buffer is empty). 1187 4. Applicability Statement 1189 The methods specified in this document MUST be applied for the 1190 transport of FC PW over uncontrolled (i.e., providing excess 1191 information rate for the service) networks, in order to provide 1192 reliable Fibre Channel transport and TCP-friendly behavior under 1193 network congestion. 1195 5. Normative References 1197 [FC-encap] Roth, M., et al, "Encapsulation Methods for Transport of 1198 Fibre Channel frames Over MPLS Networks", RFC TBD, to 1199 appear. 1200 RFC Editor: Please contact authors to obtain the correct 1201 RFC number and date for the "to appear" in the above 1202 reference prior to publication. 1204 [RFC3985] Bryant, S., et al, "Pseudo Wire Emulation Edge-to-Edge 1205 (PWE3) Architecture", RFC 3985, March 2005. 1207 [RFC3916] Xiao, X., et al, "Requirements for Pseudo Wire Emulation 1208 Edge-to-Edge (PWE3)", RFC 3916, September 2004. 1210 [RFC3448] Floyd, S., et al, "TCP Friendly Rate Control (TFRC): 1211 Protocol Specification", draft-ietf-dccp-rfc3448bis-06, 1212 April 2008. 1214 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to 1215 Edge Emulation (PWE3)", RFC 4447, April 2006. 1217 [RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance 1218 using the Label Distribution Protocol (LDP)", RFC 4447, 1219 April 2006. 1221 [RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge 1222 (PWE3) Control Word for use over an MPLS PSN", RFC 4385, 1223 February 2006. 1225 [RFC4623] Malis, A., Townsley, M., "PWE3 Fragmentation and 1226 Reassembly", RFC 4623, August 2006. 1228 [FC-BB] "Fibre Channel Backbone-4" (FC-BB-4), ANSI INCITS 1229 419:2008, to appear. 1230 RFC Editor: Please contact authors to obtain the correct 1231 date for the "to appear" in the above reference prior to 1232 publication. 1234 [FC-SW] "Fibre Channel - Switch Fabric - 4" (FC-SW-4), ANSI 1235 INCITS 418:2006, April 2006. 1237 [FC-FS] "Fibre Channel - Framing and Signaling - 2" (FC-FS-2), 1238 ANSI INCITS 424:2007, February 2007. 1240 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1241 requirement Levels", BCP 14, RFC 2119, March 1997. 1243 6. Informative references 1245 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1246 Technology", RFC 3668, February 2004. 1248 [RFC3821] M. Rajogopal, E. Rodriguez, "Fibre Channel over TCP/IP 1249 (FCIP)", RFC 3821, July 2004. 1251 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 1252 September 2000. 1254 [RFC2581] Allman, M., et al, "TCP Congestion Control", RFC 2581, 1255 April 1999. 1257 7. Author's Addresses 1259 Moran Roth 1260 Corrigent Systems 1261 101, Metro Drive 1262 San Jose, CA 95110 1263 Phone: +1-408-392-9292 1264 Email: moranr@corrigent.com 1266 Ronen Solomon 1267 Corrigent Systems 1268 126, Yigal Alon st. 1269 Tel Aviv, ISRAEL 1270 Phone: +972-3-6945316 1271 Email: ronens@corrigent.com 1273 Munefumi Tsurusawa 1274 KDDI R&D Laboratories Inc. 1275 Ohara 2-1-15, Fujimino-shi, 1276 Saitama, Japan 1277 Phone: +81-49-278-7828 1279 8. Contributing Author Information 1281 David Zelig 1282 Corrigent Systems 1283 126, Yigal Alon st. 1284 Tel Aviv, ISRAEL 1285 Phone: +972-3-6945273 1286 Email: davidz@corrigent.com 1288 Leon Bruckman 1289 Corrigent Systems 1290 126, Yigal Alon st. 1291 Tel Aviv, ISRAEL 1292 Phone: +972-3-6945694 1293 Email: leonb@corrigent.com 1295 Luis Aguirre-Torres 1296 Corrigent Systems 1297 101 Metro Drive 1298 San Jose, CA 95110 1299 Phone: +1-408-392-9292 1300 Email: Luis@corrigent.com