idnits 2.17.1 draft-bberry-rfc4938bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1068. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4938, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 567 has weird spacing: '... factor and a...' == Line 840 has weird spacing: '...able to recei...' -- 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.) -- The document date (April 24, 2008) is 5845 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC4938bis' on line 868 -- Obsolete informational reference (is this intentional?): RFC 4938 (ref. '4') (Obsoleted by RFC 5578) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft B. Berry (Editor) 2 Intended status: Informational S. Ratliff 3 Obsoletes: 4938 E. Paradise 4 Expires: October 24, 2008 Cisco 5 T.Kaiser 6 Harris Corporation 7 M. Adams 8 L3 Communications 9 April 24, 2008 11 PPP Over Ethernet (PPPoE) Extensions 12 for Credit Flow and Link Metrics 14 draft-bberry-rfc4938bis-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document extends the Point-to-Point over Ethernet (PPPoE) 47 Protocol with an optional credit-based flow control mechanism and 48 an optional Link Quality Metric report. These optional extensions 49 improve the performance of PPPoE over media with variable bandwidth 50 and limited buffering, such as mobile point-to-point radio links. 52 Table of Contents 54 1.0 Introduction .................................................2 55 2.0 Terminology ..................................................3 56 3.0 Overview of Protocol Extensions ..............................3 57 3.1 TLVs..........................................................4 58 3.1.1. Credit TLV .................................................5 59 3.1.2. Metric TLV .................................................5 60 3.1.3. Sequence Number TLV ........................................7 61 3.1.4. Credit Scale Factor TLV ....................................7 62 3.2 Discovery Stage Extensions ...................................8 63 3.2.1. PPPoE Active Discovery Request (PADR) ......................8 64 3.2.2. PPPoE Active Discovery Session-confirmation (PADS) ........10 65 3.2.3. PPPoE Active Discovery Session-Grant (PADG) ...............12 66 3.2.4. PPPoE Active Discovery Session-Credit Response (PADC) .....14 67 3.2.5. PPPoE Active Discovery Quality (PADQ) .....................15 68 3.3 PPP Session Stage Extensions ................................17 69 4.0 Credit Flow Considerations ..................................18 70 5.0 PADG and PADC Retransmission ................................19 71 6.0 Other Considerations ........................................19 72 7.0 IANA Considerations .........................................20 73 8.0 Security Considerations .....................................20 74 9.0 References ..................................................21 75 10.0 Appendix ...................................................22 77 1.0 Introduction 79 PPP over Ethernet (PPPoE) [2] is a protocol for establishing and 80 encapsulating sessions between hosts (clients) and traffic access 81 aggregators (servers) for PPP [1] transport over real or emulated 82 Ethernet. PPPoE works well when both session endpoints have similar 83 bandwidth, forwarding, and buffering capabilities that do not vary 84 over time. However, improvements can be made for applications with 85 variable bandwidth and limited buffering. This document addresses 86 these improvements with optional extensions to PPPoE that support 87 credit-based session flow control and session-based link metric 88 quality reports. 90 These extensions are designed to support radio systems that exhibit 91 point-to-point waveforms. The diagram below is used to illustrate 92 the improvement that these extensions address. When the local 93 client (radio) detects the presence of a remote radio neighbor, it 94 initiates a PPPoE session with its local server (router). The radio 95 also establishes a radio link connection with the remote radio over 96 the point-to-point RF link (which is beyond the scope of this 97 document). The remote radio is also establishing a PPPoE session 98 with its local server (router). The radios associate the two PPPoE 99 sessions and the point-to-point radio link protocol (RLP) creating 100 a complete data path. Now a PPP session is established via the PPP 101 IP Control Protocol (IPCP) as described in RFC 1661. Included in 102 this IPCP exchange is the router IP address. With the exchange of 103 the IPCP IP addresses, each router inserts the remote IP address 104 into its local routing tables. Note that the radio IP information 105 is not inserted into the routing tables. 107 |-----Local Neighbor-----| |-----Remote Neighbor----| 109 +--------+ +-------+ +-------+ +--------+ 110 | Router |=======| Radio |{~~~~~~~~}| Radio |=======| Router | 111 | Server | | Client| | Client| | Server | 112 +--------+ +-------+ +-------+ +--------+ 114 | | | | | | 115 |-PPPoE-| |----RLP---| |-PPPoE-| 116 | | 117 |-----------PPP IPCP (IP Address)---------| 118 | | 119 |-------------PPP Data Session-------------| 121 Figure 1. PPPoE Network 123 The capabilities of the RF links between RLP neighbors will vary 124 over time due to mobility, changes in the RF waveforms and encoding 125 as well as environmental conditions. To reflect these dynamic 126 changes, the radio may periodically generate Link Quality Metrics 127 to the router. The router uses the link metric to update route 128 costs and influence route selection. The influence upon the routing 129 protocols is beyond the scope of this document. 131 An open source (GPLv2) pppoe client implementation can be found 132 at [4]. 134 2.0 Terminology 136 Access Concentrator 137 The RFC 2516 term used to describe the server. This 138 document uses the terms Router or Server. 140 BCN Backward Credit Notification, The BCN represent the 141 local node remaining credits that were granted from 142 the peer node. The local node uses these credits 143 to transmit payload back to the peer node. BCN 144 ranges from 0-65535. 146 CDR Current Data rate 147 FCN Forward Credit Notification. The FCN represents the 148 credits that the local node is granting to the peer node. 149 The peer node uses these granted credits to transmit 150 payload back to the local node. FCN ranges from 0-65535. 152 gbps gigabits (1,000,000,000) per second 154 Host The RFC 2516 term used to describe the server. This 155 document uses the terms Radio or Client. 157 kbps kilobits (1,000) per second 159 LCP PPP Link Control Protocol, RFC 1661 161 mbps megabits (1,000,000) per second 163 MDR Maximum Data rate 165 NCP PPP Network Control Protocol, RFC 1661 167 RLP Radio Link Protocol 169 TAG Is the RFC 2516 PPPoE Synonym for TLV. This document 170 uses TLV. 172 tbps terabits (1,000,000,000,000) per second 174 TLV Type-Length-Value 176 3.0 Overview of Protocol Extensions 178 The extensions consist of optional TLVs, enhanced and newly defined 179 Discovery packets. The enhancements are applied to the Discovery 180 Stage and the PPP Session Stage. 182 3.1 TLVs 183 The new TLVs are listed in the table below: 185 TLV TLV 186 Value Description 187 ========================================= 188 0x0106 Credit TLV 189 0x0107 Metric TLV 190 0x0108 Sequence Number TLV 191 0x0109 Credit Scale Factor TLV 193 3.1.1 Credit TLV 195 This TLV contains the Forward Credit Notification (FCN) and the 196 Backward Credit Notification (BCN). The Credit TLV is optional 197 with the PADR and PADS and required in the PADG and PADC Discovery 198 Packets (ETHER_TYPE=8863). 200 The Credit TLV is optionally carried in the PPPoE data payload 201 packet of the PPP Stage (ETHER_TYPE=8864). 203 The FCN represents the number of credits being granted by the 204 local node to the peer node. The BCN represents the number of 205 credits remaining at the local node that were granted by the 206 peer node. 208 The Credit TLV is shown below: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Credit TLV = 0x0106 | TLV Length = 0x04 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | FCN | BCN | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 3.1.2 Metric TLV 220 The Metric TLV is used to report the link quality parameters. The 221 Metric TLV is required with the PADQ Discovery Packet. 223 The Metric TLV contains the following fields: 225 Resources - a percentage, 0-100, representing the amount of 226 remaining or available resources, such as battery power. If 227 resources cannot be calculated, a value of 100 should be 228 reported. 230 Relative Link Quality (RLQ) - a non-dimensional number, 0-100, 231 representing the relative link quality. A value of 100 232 represents a link of the highest quality. If the RLQ cannot 233 be calculated, a value of 100 should be reported. 235 Receive only - a bit that indicates whether the link is bi- 236 directional or receive only. A value of -1- indicates that 237 the link is receive-only. 239 Reserved - Reserved fields are zeroed unless otherwise 240 specified. 242 CD - Two bits that designate the units of the current data rate. 244 CD Scale: 00 == kbps (default) 245 01 == mbps 246 10 == gbps 247 11 == tbps 249 MD - Two bits that designate the units of the maximum data rate. 251 MD Scale: 00 == kbps (default) 252 01 == mbps 253 10 == gbps 254 11 == tbps 256 Current data rate - the current data rate, in un scaled units 257 per second, achieved on the RLP link. If the radio makes no 258 distinction between maximum data rate and current data rate, 259 current data rate should equal the maximum data rate. When 260 metrics are reported, the current data rate must be reported. 261 The current data rate must be less than or equal to the maximum 262 data rate. 264 Latency - the transmission delay that a packet encounters as 265 it is transmitted over the link. This is reported in absolute 266 delay, milliseconds. If latency cannot be calculated, a value 267 of 0 should be reported. The calculation of latency is radio 268 dependent. For example, the latency may be a running average 269 calculated from the internal queuing. 271 Maximum data rate - the maximum theoretical data rate, in 272 un scaled units per second, that the RLP link is capable of 273 providing. When metrics are reported, the maximum data rate 274 must be reported. 276 The Metric TLV is shown below: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Metric TLV = 0x0107 | TLV Length = 0x0A | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Reserved | MD| CD|R| RLQ | Resources | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Latency (MS) | Current Datarate | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Maximum Datarate | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 3.1.3 Sequence Number TLV 292 This TLV is used to carry a unique 16-bit sequence number in order 293 to identify a specific request and the associated response. The 294 sequence number should be initialized to zero and incremented by one 295 for each new request. For retransmitted packets, the same sequence 296 number that was used in the previous packet transmission is repeated. 297 The PADG and PADC packets require the Sequence Number Tag. 299 The Sequence Number TLV is shown below: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Sequence Number TLV = 0x0108 | TLV Length = 0x02 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Sequence Number | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 3.1.4 Credit Scale Factor TLV 311 This TLV contains the scale factor value that is to be applied to 312 the session credit calculations. The Credit Scale Factor TLV is 313 optional with the PADR, PADS packets. Once the session is 314 established with specified scale factors, the scale factors are 315 set for the entire session. The scale factor value represents 316 the units that the local node grants to the remote node. The 317 remote node is responsible for maintaining the credit accounting 318 relative to the data flow back to the local node. 320 The Credit Scale Factor TLV can be used to change from the 321 default 64-byte credit unit during the PADR-PADS exchange. The 322 credit scale factor value can range from 1-byte to 65535-bytes. 323 A zero value is ignored and the default 64-byte unit remains set. 324 The scale factor is set per each payload flow: peer-to-local and 325 local-to-peer. 327 The Credit Scale Factor TLV is shown below: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Credit Scale Factor = 0x0109 | TLV Length = 0x02 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Scale Factor Value | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 3.2 Discovery Stage Extensions 339 The specifications of the Session Request (PADR) and the Session 340 Confirmation (PADS) packets are extended to include the optional 341 Credit TLV and the Credit Scale Factor TLV. The Credit Grant (PADG) 342 packet, the Grant Confirmation (PADC) packet and the Quality packet 343 are newly defined Discovery Stage Packets. 345 Discovery 346 Packet Status 347 ======================================================= 348 PADR Enhanced Optionally includes the Credit 349 TLV and the Credit Scale Factor 350 TLV 352 PADS Enhanced Optionally includes the Credit 353 TLV and the Credit Scale Factor 354 TLV 356 PADG New Includes the Credit TLV and the 357 Sequence Number TLV 359 PADC New Includes the Credit TLV and the 360 Sequence Number TLV 362 PADQ New Includes the Metric TLV 364 3.2.1 PPPoE Active Discovery Request (PADR) 366 The PADR packet is extended to optionally contain a single Credit 367 TLV, indicating that the Client requests credit flow control for 368 this session. The Credit TLV contains the Forward Credit Notification 369 (FCN) and the Backward Credit Notification (BCN) to be applied to 370 the PPP Session Stage. The FCN provides the initial credits granted 371 to the Server by the Client. The BCN value is set to 0 as the Client 372 has not yet been granted credits from the Server. 374 The PADR packet is enhanced to optionally contain a single Credit 375 Scale Factor TLV. The Credit Scale Factor TLV defines the credit 376 scale factor value. If the Credit Scale Factor TLV is omitted, the 377 default 64-byte value is used for the session. When the client 378 includes the optional Credit Scale Factor TLV in the PADR, this 379 credit scale factor value is applied to all credit grants associated 380 with the client credits that are granted to the server. 382 The Server must echo the Credit Scale Factor TLV in the PADS 383 response to confirm the credit scaling session and to designate the 384 server credit scaling factor. This PADS Credit Scaling Factor TLV 385 represents the scale factor value that is applied to all credits 386 granted from the Server to the Client. 388 Once the session is established during the PADR-PADS exchange, the 389 credit scale factor value can not be changed. 391 A Discovery PADR packet with optional Credit TLV is shown below: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Access_Concentrator_mac_addr | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Host_mac_addr (cont) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | SESSION_ID = 0x1234 | LENGTH = 0x0C | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | TLV Type = 0x0101 | Metric TLV Length = 0x00 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Credit TLV = 0x0106 | TLV Length = 0x04 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | FCN | BCN = 0 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 The credit units are expressed in the default 64-byte units. 415 A Discovery PADR packet with the optional Credit TLV and the optional 416 Credit Scale Factor TLV is shown below: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Access_Concentrator_mac_addr | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Host_mac_addr (cont) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | SESSION_ID = 0x1234 | LENGTH = 0x0C | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | TLV Type = 0x0101 | TLV Length = 0x00 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Credit TLV = 0x0106 | TLV Length = 0x04 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | FCN | BCN = 0 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Credit Scale Factor = 0x0109 | TLV Length = 0x02 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | scale factor value | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 The Credit TLV FCN value is expressed in units of the session 443 credit scale factor value. 445 3.2.2 PPPoE Active Discovery Session-confirmation (PADS) 447 The Server PADS is extended to optionally contain a single Credit 448 TLV, indicating the Forward Credit Notification (FCN) and the 449 Backward Credit Notification (BCN) of the PPP Session Stage. 451 If the Client PADR contained a Credit TLV, then the Server PADS 452 must indicate support for credit flow control by including 453 a Credit TLV. The PADS Credit TLV FCN represents the number of 454 credits initially granted to the Client. The Credit TLV BCN is an 455 echo of the number of credits that the Client had granted to the 456 Server in the originating PADR packet. 458 Exchange of the Credit TLV in the PADR and PADS indicates that 459 credit flow control is supported by both the Server and the Client 460 for the designated PPP Session Stage. This is binding and must 461 be followed for the entire duration of the PPP Session Stage. A 462 session's credit binding must be established prior to any other 463 credit indications can be exchanged. 465 The Server PADS should only include the Credit TLV in response to 466 a Client PADR which included the Credit TLV. If the Server does 467 not support credit flow, it should not include the Credit TLV in 468 its PADS response. The Client must terminate a credit-based session 469 that cannot be supported by the Server. A Credit TLV transmitted 470 outside an established credit based session must be ignored. 472 The Server PADS is enhanced to optionally contain a single Credit 473 Scale Factor TLV. The Credit Scale Factor TLV defines the credit 474 scale unit value. The Credit Scale Factor TLV must be included if 475 it was included in the Client PADR. If the Credit TLV was not 476 included in the originating PADR, it must be omitted, indicating 477 that the 64-byte default is used for the directional flow. This 478 credit scale factor is applied to Server grants to the Client. 480 A Discovery PADS packet with the optional Credit TLV is shown 481 below: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Access_Concentrator_mac_addr | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Host_mac_addr (cont) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | SESSION_ID = 0x1234 | LENGTH = 0x0C | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | TLV Type = 0x0101 | TLV Length = 0x00 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Credit TLV = 0x0106 | TLV Length = 0x04 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | FCN | BCN | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 The BCN is expressed in the default 64-byte units. 505 A Discovery PADS packet with the optional Credit TLV and the optional 506 Credit Scale Factor TLV is shown below: 508 0 1 2 3 509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Access_Concentrator_mac_addr | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Host_mac_addr (cont) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | SESSION_ID = 0x1234 | LENGTH = 0x0C | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TLV Type = 0x0101 | TLV Length = 0x00 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Credit TLV = 0x0106 | TLV Length = 0x04 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | FCN | BCN | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Credit Scale Factor = 0x0109 | TLV Length = 0x02 | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | scale factor value | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 The Credit TLV BCN value is expressed in units of the session 533 scale factor value received in the PADR. 535 3.2.3 PPPoE Active Discovery Session-Grant (PADG) 537 The PPPoE Active Discovery Session-Grant (PADG) is a new packet 538 defined in this specification. The local node (Server or Client) 539 may send a PADG at any time after the PADR/PADS exchange to grant 540 incremental flow control credits to a peer. The CODE field is set 541 to 0x0A and the SESSION_ID must be set to the unique value 542 generated for this PPPoE Session. 544 Each flow control credit corresponds to the amount of PPP payload 545 bytes that can be sent or received. For example, if the default 546 credit scale factor of 64-bytes is used, and 128 bytes of PPP 547 payload data is sent, then 2 credits would be consumed. When 548 calculating credits to consume, all credit calculations must be 549 rounded up. If in the previous example 130 bytes of PPP payload 550 data was sent, 3 credits would have been consumed. 552 When the peer receives a PADG packet, it adds the incremental 553 credits to its working credit count and responds with a PPPoE 554 Active Discovery Session-Credit (PADC) packet indicating the 555 accumulation of the credits. The FCN and BCN values must be 556 scaled by the value established during session establishment 557 in the Credit Scale Factor TLV or by the default 64-byte 558 value prior to processing. 560 The PADG packet must contain a single Credit TLV, indicating 561 the Forward Credit Notification (FCN) and the Backward Credit 562 Notification (BCN) of the PPPoE Session. 564 The Credit TLV FCN indicates the number of incremental credits 565 being granted to the peer by the node. A value between 1 and 566 0xffff represents an incremental credit grant. The peer must 567 multiply the credits units by the credit scale factor and add 568 these credits to its accumulated transmit credit count. A value 569 of 0x0000 represents a NULL grant, meaning that there are no 570 additional credits being granted. 572 The Credit Tag BCN indicates the remaining absolute credits that 573 have been granted by the peer to the local node. When the local 574 node exhausts the BCN, it must stop transmitting payload packets. 576 Once a credit has been granted, it must be honored. The largest 577 number of incremental credits at any time is 0xffff. 579 The PADG packet must contain a single Sequence Number TLV. This 580 tag is used to carry a unique 16-bit sequence number to uniquely 581 to identify each request. The sequence number should be 582 initialized zero and incremented by one for each new PADG. For 583 retransmitted PADGs, the same sequence number that was used in 584 the previous packet transmission is repeated. 586 A Discovery PADG packet with the Sequence Number and Credit TLVs 587 is shown below: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Destination_mac_addr | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Destination_mac_addr(c) | Source_mac_addr | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Source mac_addr (cont) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0A | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | SESSION_ID = 0x1234 | LENGTH = 0x0E | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sequence Number TLV = 0x0108 | TLV Length = 0x02 | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Sequence Number | Credit TLV = 0x0106 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | TLV Length = 0x04 | FCN | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | BCN | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 3.2.4 PPPoE Active Discovery Session-Credit Response (PADC) 613 The PPPoE Active Discovery Session-Credit Response (PADC) is a new 614 packet defined in this specification. A Server or Client must send 615 a PADC in response to a PADG. The CODE field is set to 0x0B, and 616 the SESSION_ID must be set to the unique value generated for this 617 PPPoE session. 619 The PADC packet must contain a single Credit Tag TLV, indicating 620 the Forward Credit Notification (FCN) and the Backward Credit 621 Notification (BCN) of the PPPoE session. 623 The Credit TLV FCN represents the absolute credits remaining that 624 have been granted to the peer by the node. The Credit TLV BCN 625 represents the remaining absolute credits that have been granted 626 to the local node from the peer. The FCN and BCN values must be 627 scaled by the value established during session establishment in 628 the Credit Scale Factor TLV or by the default 64-byte value prior 629 to processing. 631 The PADC packet must contain a single Sequence Number Tag.The 632 sequence number must be the sequence number associated with the 633 PADG. 635 A Discovery PADC packet with the Sequence Number and Credit TLV 636 is shown below. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Destination_mac_addr | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Destination_mac_addr(c) | Source_mac_addr | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Source mac_addr (cont) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0B | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | SESSION_ID = 0x1234 | LENGTH = 0x0E | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Sequence Number TLV = 0x0108 | TLV Length = 0x02 | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Sequence Number | Credit TLV = 0x0106 | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | TLV Length = 0x04 | FCN | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | BCN | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 The FCN and BCN values are expressed in the respective units 661 defined by the Credit Scale Factor TLV or the 64-byte default. 663 3.2.5 PPPoE Active Discovery Quality (PADQ) 665 The PPPoE Active Discovery Quality (PADQ) is a new packet defined 666 in this specification. An Server or Client may send an optional 667 PADQ at any time to query or report link quality metrics. 669 When transmitting PPP [1] streams over wireless links through radio 670 modems, the quality of the RF link directly affects the throughput. 671 The PPPoE Active Discovery Quality (PADQ) packet can be used by the 672 radio modem to report RF link metrics. The CODE field is set to 673 0x0C, and the SESSION_ID must be set to the unique value generated 674 for this PPPoE session. 676 The PPPoE Active Discovery Quality (PADQ) packet can be used to 677 query link metrics by setting the PADQ Metric Tag Length to zero. 679 The PADQ must carry a single Metric TLV. When processing the 680 data rates, the values must be converted using the indicated 681 data rate units. This document enhances the Metric Tag as 682 described below. 684 The PPPoE Active Discovery Quality (PADQ) packet can be used to 685 query link metrics by setting the PADQ Metric Tag Length to zero. 687 A Discovery PADQ packet with the required Metric TLV is shown 688 below: 690 0 1 2 3 691 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Access_Concentrator_mac_addr | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Host_mac_addr (cont) | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | SESSION_ID = 0x1234 | LENGTH = 0x12 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | TLV Type = 0x0101 | TLV Length = 0x00 | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Metric TLV = 0x0107 | TLV Length = 0x0A | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Reserved | MD| CD|R| RLQ | Resources | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Latency (MS) | Current Datarate | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Maximum Datarate | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 The maximum datarate and the current datarate are expressed in 715 units determined by the MD and CD bits, respectively. 717 A Discovery PADQ packet with a Metric TLV Length=0 to query for 718 is shown below: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Access_Concentrator_mac_addr | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Host_mac_addr (cont) | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | SESSION_ID = 0x1234 | LENGTH = 0x08 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | TLV Type = 0x0101 | TLV Length = 0x00 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Metric TLV = 0x0107 | TLV Length = 0x00 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 3.3 PPP Session Stage Extensions 740 The PPP Session Stage Extensions define the optional use of Credit 741 TLV. Use of the Credit TLV in the PPP Session Stage is referred 742 to as an in-band credit grant. 744 The first field following the PPP Session Stage LENGTH must be 745 checked. If the value is equal to the PPP Protocol identifier 746 (0xc021), then normal packet (payload) processing occurs. 747 When the field following the PPP Session Stage LENGTH is not 748 the PPP Protocol identifier (0xc021), a TLV is assumed. In 749 this case, the TLV length is subtracted from the overall payload 750 length. 752 A PPP LCP packet with optional Credit TLV is shown below: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Access_Concentrator_mac_addr | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Host_mac_addr (cont) | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | SESSION_ID = 0x1234 | LENGTH = (payload) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Credit TLV = 0x0106 | TLV Length = 0x04 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | FCN | BCN | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | PPP PROTOCOL = 0xc021 | PPP payload ~ 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 4.0 Credit Flow Considerations 776 For a given session, credit grants exchanged in the Discovery Stage, 777 PADG-PADC, are referred to as out-of-band. Credit grants exchanged 778 in the PPP Session Stage are referred to as in-band. Credit 779 accounting is only applied to the packets transmitted in the PPP 780 Session Stage. 782 Out-of-band credit management is handled by periodic exchange of 783 the PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery 784 Credit (PADC) packets. 786 In-band credit management allows credits to be incrementally 787 granted with each PPP Session Stage packet. These in-band 788 incremental credit grants are not explicitly acknowledged. 789 However, they are reflected in the in-band credit flow from 790 the peer node. This offers the greatest credit granting efficiency 791 when traffic rates are high. 793 Once agreed upon during the Discovery Stage, credit grants are 794 required to transmit packets in the PPP Session Stage. A node must 795 grant credits to its peer, before the peer can transmit packets to 796 the granting node. 798 Credits are granted incrementally in the forward direction. Locally, 799 a node manages the credits that it has granted to a peer, as well 800 as the credits that a peer has granted to it. 802 Grants received from a peer are added to a local running credit 803 counter. The accumulated credits are decremented with each packet 804 the node transmits to the peer. When the running counter reaches 805 zero, the node must stop transmitting packets to the peer. 807 To manage the credits that a node has granted, the node maintains a 808 running counter. With each PPP Session Stage packet received from 809 the peer, the running counter is decremented. When the running 810 counter reaches zero, no additional packets are expected. The node 811 incrementally grants more credits to the peer to maintain packet 812 flow. Packets received when granted credits have been exhausted 813 are discarded. 815 5.0 PADG and PADC Retransmission 817 When a node does not receive a PADC packet in response to a PADG 818 within a specified amount of time, it should transmit a new PADG 819 packet with zero credits, using the same sequence number and double 820 the waiting period. A PADC response with the associated sequence 821 number will indicate whether or not the previously granted credits 822 were accumulated. If they were not, a PADG with credits, with an 823 incremented sequence number, should be transmitted. This process 824 should be repeated until granted credits are properly acknowledged 825 or as many times as desired. 827 When a node does not receive a PADQ metric packet in response to a 828 query within a specified amount of time, it should resend the PADQ 829 query packet and double the waiting period. This can be repeated 830 as many times as desired. 832 6.0 Other Considerations 834 A node may autonomously generate PADQ metric packets. The rate of 835 autonomously generated PADQ metric packets may need to be throttled 836 so as not to overrun the peer. 838 The sending and receiving of PPPoE Discovery packets are 839 independent of credit counts. For example, a node must always 840 be able to receive a PADG and send a PADC. 842 During normal operation, nodes may disagree about the number of 843 credits. Operational credit mismatches would occur due to packets 844 in transit on the wire. Much larger credit mismatches can occur if 845 there are transmission errors. To correct these larger errors, the 846 BCN fields of the PADG and PADC packets and in-band credit grants 847 from a peer can be used by the receiving node to reset the credit 848 values of its peer. 850 7.0 IANA Considerations 852 IANA has assigned the following PPPoE TLV Values as noted in [3]: 854 TLV Value TLV Name Description Reference 855 ----------- ------------------- ----------------- --------- 856 262 0x0106 Credits See the reference [RFC4938bis] 857 263 0x0107 Metrics See the reference [RFC4938bis] 858 264 0x0108 Sequence Number See the reference [RFC4938bis] 859 265 0x0109 Credit Scale Factor See the reference [RFC4938bis] 861 IANA has assigned the following PPPoE Code fields as noted in [3]: 863 Code PPPoE Packet Name Description Reference 864 -------- ---------------------- ----------------- --------- 865 10 0x0a PADG, Session-Grant See the reference [RFC4938bis] 866 11 0x0b PADC, Session-Credit See the reference [RFC4938bis] 867 Response 868 12 0x0c PADQ, Quality See the reference [RFC4938bis] 870 8.0 Security Considerations 872 This memo defines a mechanism for adding flow control to the 873 existingPPP Over Ethernet (PPPoE) sessions. These extensions 874 are subsequent to the existing PPPoE security mechanisms as 875 described in RFC 2516 [2]. It is required that the Service TLV 876 and Session ID always be validated prior to processing credits. 878 9.0 References 880 9.1 Normative References 882 [1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, 883 RFC 1661, July 1994. 885 [2] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. 886 Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", 887 RFC 2516, February 1999. 889 [3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over 890 Ethernet (PPPoE)", RFC 4937, June 2007. 892 9.2 Informative References 894 [4] An open source (GPLv2) pppoe client implementation of 895 RFC4938bis, PPP Over Ethernet (PPPoE) Extensions for Credit 896 Flow and Link Metrics, 897 http://rfc4938.sourceforge.net/ 899 10.0 Appendix 901 Session Credit Flow with the default 64-byte credit unit. 903 Server Client 904 ====================================================================== 905 <------------PADI-------------- Initiate 906 ------------PADO--------------> Offer 908 <------------PADR-------------- Credit TLV: 909 FCN represents the initial 910 client credit grant to the 911 server in 64-byte units. 912 BCN is set to 0. 914 ------------PADS--------------> Credit TLV: 915 FCN represents the initial 916 server credit grant to the 917 client in 64-byte units. 918 BCN represents an echo of 919 initial client credits. 921 <==============================> Data w/ optional inband 922 Credit TLV 924 <------------PADG-------------- Credit TLV: (out-of-band) 925 FCN represents an incremental 926 client credit grant to the 927 server, in 64-byte units. 928 BCN represents the remaining 929 server credits that were granted 930 to the client, in 64-byte units. 932 ------------PADC--------------> Credit TLV: (out-of-band) 933 FCN represents an incremental 934 server credit grant to the 935 client, in 64-byte units. 936 BCN represents the remaining 937 client credits that were granted 938 to the server, in 64-byte units. 940 <==============================> Data w/ optional inband Credit 941 TLV 943 <------------PADT--------------> Terminate 945 Session Credit Flow with specific credit scale factor units for 946 the Server and the Client. 948 Server Client 949 ====================================================================== 950 <------------PADI-------------- Initiate 951 ------------PADO--------------> Offer 953 <------------PADR-------------- Credit TLV: 954 FCN represents the initial 955 client credit grant to the 956 server, in Credit Scale Factor 957 TLV units. 958 BCN is set to 0. 960 ------------PADS--------------> Credit TLV: 961 FCN represents the initial 962 server credit grant to the 963 client, in Credit Scale Factor 964 TLV units. 965 BCN represents an echo of the 966 initial client credits, in 967 Credit Scale Factor TLV units. 969 <==============================> Data w/ optional inband Credit 970 TLV 972 <------------PADG-------------- Credit TLV: (out-of-band) 973 FCN represents an incremental 974 client credit grant to the server, 975 in Credit Scale Factor TLV units. 976 BCN represents the remaining 977 server credits that were granted 978 to the client, in Credit Scale 979 Factor TLV units. 981 ------------PADC--------------> Credit TLV: (out-of-band) 982 FCN represents an incremental 983 server credit grant to the client, 984 in Credit Scale Factor TLV units. 985 BCN represents the remaining 986 client credits that were granted 987 to the server, in Credit Scale 988 Factor TLV units. 990 <==============================> Data w/ optional inband Credit 991 TLV 993 <------------PADT--------------> Terminate 995 Authors' Addresses 997 Bo Berry, Editor 998 Cisco 999 170 West Tasman Drive 1000 San Jose, CA 95134 1001 EMail: bberry@cisco.com 1003 Stan Ratliff 1004 Cisco 1005 170 West Tasman Drive 1006 San Jose, CA 95134 1007 EMail: sratliff@cisco.com 1009 Ed Paradise 1010 Cisco 1011 170 West Tasman Drive 1012 San Jose, CA 95134 1013 EMail: pdice@cisco.com 1015 Tim Kaiser 1016 Harris Corporation 1017 Government Communications System Division 1018 Mail Stop 25-11F 1019 P.O. Box 37 1020 Melbourne, FL 32902-0037 1021 EMail: timothy.kaiser@harris.com 1023 Mike D Adams 1024 640 N 2200 W MS F1J12 1025 Salt Lake City, Utah 84116 1026 801 594-2367 1027 EMail: Michael.D.Adams@L-3com.com 1029 Full Copyright Statement 1031 Copyright (C) The IETF Trust (2008). 1033 This document is subject to the rights, licenses and restrictions 1034 contained in BCP 78, and except as set forth therein, the authors 1035 retain all their rights. 1037 This document and the information contained herein are provided on 1038 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1039 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1040 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1041 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1042 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1043 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1044 FITNESS FOR A PARTICULAR PURPOSE. 1046 Intellectual Property 1048 The IETF takes no position regarding the validity or scope of any 1049 Intellectual Property Rights or other rights that might be claimed 1050 to pertain to the implementation or use of the technology described 1051 in this document or the extent to which any license under such 1052 rights might or might not be available; nor does it represent that 1053 it has made any independent effort to identify any such rights. 1054 Information on the procedures with respect to rights in RFC 1055 documents can be found in BCP 78 and BCP 79. 1057 Copies of IPR disclosures made to the IETF Secretariat and any 1058 assurances of licenses to be made available, or the result of an 1059 attempt made to obtain a general license or permission for the 1060 use of such proprietary rights by implementers or users of this 1061 specification can be obtained from the IETF on-line IPR 1062 repository at http://www.ietf.org/ipr. 1064 The IETF invites any interested party to bring to its attention 1065 any copyrights, patents or patent applications, or other 1066 proprietary rights that may cover technology that may be required 1067 to implement this standard. Please address the information to 1068 the IETF at ietf-ipr@ietf.org. 1070 Acknowledgement 1072 Funding for the RFC Editor function is currently provided by the 1073 Internet Society.