idnits 2.17.1 draft-bberry-pppoe-credit-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 198: '...n. An Access Concentrator or Host MAY...' RFC 2119 keyword, line 431: '... OPTIONAL with the PADR, PADS and t...' RFC 2119 keyword, line 485: '...PADR packet with OPTIONAL Credit Tag T...' RFC 2119 keyword, line 506: '...PADS packet with OPTIONAL Credit Tag T...' Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (10 March 2004) is 7352 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 651, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT B. Berry 2 Category: Informational H. Holgate 3 Expires: May 18, 2007 Cisco Systems,Inc. 4 10 March 2004 6 PPP Over Ethernet (PPPoE) Extensions 7 for Credit Flow and Link Metrics 9 draft-bberry-pppoe-credit-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use 26 Internet-Drafts as reference material or to cite them other than 27 as "work in progress." 29 This document may not be modified, and derivative works of it may 30 not be created, except to publish it as an RFC and to translate it 31 into languages other than English. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 29, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document extends the Point-to-Point Over Ethernet (PPPoE) 48 Protocol [2] with a credit-based flow control mechanism and 49 Link Quality Metric report. This optional extension should 50 improve the performance of PPPoE over media with variable 51 bandwidth and limited buffering, such as mobile radio links. 53 Table of Contents 55 1. Introduction..................................................3 56 2. Payload.......................................................4 57 3. Overview of Protocol Extensions...............................4 58 4. Discovery Stage...............................................4 59 4.1 PPPoE Active Discovery Request (PADR).....................4 60 4.2 PPPoE Active Discovery Session-confirmation (PADS)........5 61 4.3 PPPoE Active Discovery Session-Grant (PADG)...............5 62 4.4 PPPoE Active Discovery Session-Credit Response (PADC).....6 63 4.5 PPPoE Active Discovery Quality (PADQ).....................7 64 5. PPP Session Stage.............................................8 65 6. Credit Flow Considerations....................................8 66 7. Other Considerations..........................................9 67 8. IANA Considerations...........................................9 68 9. Security Considerations......................................10 69 10. Appendix A: Tag Values......................................10 70 11. Appendix B: Example Message Formats.........................12 71 12. Acknowledgements............................................19 72 13. Normative References........................................19 73 Authors' Addresses..............................................19 74 Intellectual Property and Copyright Statements..................20 76 1. Introduction 78 PPP over Ethernet (PPPoE) [2] is a protocol for establishing 79 and encapsulating sessions between hosts and traffic 80 aggregators (Access Concentrators) for PPP transport over real 81 or emulated Ethernet. PPPoE works well when both session 82 endpoints have similar bandwidth, forwarding, and buffering 83 capabilities that do not vary over time. However, it is 84 insufficient for applications with variable bandwidth and 85 limited buffering, for example, mobile radio links. This 86 document addresses this problem by suggesting an extension to 87 PPPoE to support credit-based session flow control and 88 session-based link metric exchanges. 90 The diagram below illustrates the problem that this extension 91 is intended to solve, for the case of a radio link. Here PPPoE 92 sessions are used between access concentrators (routers) and 93 radio transmission systems that are shown as radio neighbors. 94 Each radio transmission system establishes point-to-point Radio 95 Link Protocol (RLP) sessions with its neighbors and establishes 96 a corresponding PPPoE session for each neighbor with the 97 transmission system's associated access concentrator (router). 98 The radio logically associates the PPPoE session with the 99 corresponding RLP session. 101 +--------+ +-------+ +-------+ +--------+ 102 | Access | | Host | | Host | | Access | 103 | Conc. |=======| Radio |~~~~~~~| Radio |=======| Conc. | 104 +--------+ +-------+ +-------+ +--------+ 105 | | | | | | 106 |-PPPoE-| |--RLP--| |-PPPoE-| 107 | | 108 |-------------PPP Session---------------| 110 Figure 1: PPPoE Network 112 The capabilities of the RF links between RLP neighbors may vary 113 over time due to mobility and environmental conditions. In many 114 instances, the Host Radio has limited buffering capability to 115 handle capacity changes in the RLP sessions. To limit buffering 116 in the Host Radio, the PPPoE credit flow control mechanism 117 provides dynamic buffering feedback to the access concentrator. 119 In the diagram above, from the access concentrator's perspective, 120 each PPPoE session between it and the Host Radio represent a 121 connection to a remote routable peer. For efficient routing, 122 the local Host Radio uses the link metric mechanism to dynamically 123 update the access concentrator route cost of the associated link. 125 While the example shows an RF based application, the extensions 126 are applicable to other media. 128 2. Payload 130 The Ethernet payload version field retains its value of 0x01. The 131 extensions for credit flow control and link quality metrics are 132 optional and backward compatible. 134 3. Overview of Protocol Extensions 136 PPPoE has two distinct stages. There is a Discovery Stage and a PPP 137 Session Stage. During the Discovery Stage, the Host can optionally 138 request a flow controlled PPP Session Stage. Once the Access 139 Concentrator acknowledges the Host flow control request, all PPP 140 Session Stage traffic must be flow controlled. 142 4. Discovery Stage 144 The packet exchange of the Discovery Stage is unchanged by this 145 specification. The specifications of the Session Request (PADR) and 146 the Session Confirmation (PADS) packets are extended to include the 147 optional Credit Tag Type-Length-Value (TLV). 149 In addition, the optional Credit Grant (PADG) packet, the Credit 150 Response (PADC) packet and the Link Quality Metric (PADQ) packets 151 are introduced. 153 4.1 PPPoE Active Discovery Request (PADR) 155 The PADR packet is extended to optionally contain a single Credit 156 Tag TLV, indicating that the Host requests credit flow control for 157 this session. The Credit Tag contains the Forward Credit 158 Notification (FCN) and the Backward Credit Notification (BCN) to be 159 applied to the PPP Session Stage. The FCN provides the initial 160 credits granted to the Access Concentrator by the Host. The BCN 161 value is set to 0. 163 An example packet is shown in Appendix B. 165 4.2 PPPoE Active Discovery Session-confirmation (PADS) 167 The PADS packet is extended to optionally contain a single Credit 168 Tag TLV, indicating the Forward Credit Notification (FCN) and the 169 Backward Credit Notification (BCN) of the PPP Session Stage. 171 If the PADR contained a Credit Tag, then the Access Concentrator 172 PADS packet indicates support for credit flow control by including a 173 Credit Tag. The PADS Credit Tag FCN represents the number of 174 credits being initially granted to the Host. The Credit Tag BCN is 175 an echo of the number of credits that the Host had granted to the 176 Access Concentrator in the previous PADR packet. 178 Exchange of the Credit Tag TLV in the PADR and PADS indicates that 179 credit flow control is supported by both the Access Concentrator and 180 the Host for the designated PPP Session Stage. This is binding and 181 must be followed for the entire duration of the PPP Session Stage. 182 A session�s credit binding must be established prior to any other 183 credit indications can be exchanged. 185 The Access Concentrator PADS should only carry the Credit Tag in 186 response to a Host PADR with Credits. If the Access Concentrator 187 does not support credit flow, it should not include the Credit Tag 188 in its PADS response. The Host must terminate a credit based 189 session that can not be supported by the Access Concentrator. 190 Credit Tags transmitted outside an established credit based session 191 must be ignored. 193 An example packet is shown in Appendix B. 195 4.3 PPPoE Active Discovery Session-Grant (PADG) 197 The PPPoE Active Discovery Session-Grant (PADG) is a new packet 198 defined in this specification. An Access Concentrator or Host MAY 199 send a PADG at any time after the PADR/PADS exchange to grant 200 incremental flow control credits. The CODE field is set to 0x0A and 201 the SESSION_ID must be set to the unique value generated for this 202 PPPoE Session. 204 The peer may then transmit data until the credits are exhausted. 206 When the peer receives a PADG packet, it adds the incremental 207 credits to its working credit count and responds with a PPPoE Active 208 Discovery Session-Credit (PADC) packet indicating the accumulated 209 credits. 211 The PADG packet must contain a single Credit Tag TLV, indicating the 212 Forward Credit Notification (FCN) and the Backward Credit 213 Notification (BCN) of the PPP Session. 215 The Credit Tag FCN indicates the number of incremental credits 216 being granted to the peer by the node. A value between 1 and 217 0xffff represent an incremental credit grant. The peer must 218 add these credits to its accumulated transmit credit count. 219 A value of 0x0000 represents a NULL grant, meaning that there 220 are no additional credits being granted. 222 The Credit Tag BCN indicates the remaining absolute credits that 223 have been granted by the peer to the node. 225 Once a credit has been granted, it must be honored. The largest 226 number of outstanding credits at any time is 0xffff. 228 The PADG packet must contain a single Sequence Number Tag TLV. This 229 tag is used to carry a unique 16-bit sequence number to uniquely 230 identify each request. The sequence number should be initialized to 231 zero and incremented by one for each new PADG. For re-transmitted 232 PADGs, the same sequence number that was used in the previous packet 233 transmission is repeated. 235 An example packet is shown in Appendix B. 237 4.4 PPPoE Active Discovery Session-Credit Response (PADC) 239 The PPPoE Active Discovery Session-Credit Response (PADC) is a new 240 packet defined in this specification. An Access Concentrator or 241 Host must send a PADC in response to a PADG. The CODE field is set 242 to 0x0B and the SESSION_ID must be set to the unique value generated 243 for this PPPoE session. 245 The PADC packet must contain a single Credit Tag TLV, indicating the 246 Forward Credit Notification (FCN) and the Backward Credit 247 Notification (BCN) of the PPPoE session, and any number of other Tag 248 types. 250 The Credit Tag FCN represents the absolute credits remaining that 251 have granted to the peer by the node. The Credit Tag BCN represents 252 the remaining absolute credits that have been granted to the node 253 from the peer. 255 The PADC packet must contain a single Sequence Number Tag. The 256 sequence number must be the sequence number associated with the 257 PADG. 259 An example packet is shown in Appendix B. 261 4.5 PPPoE Active Discovery Quality (PADQ) 263 The PPPoE Active Discovery Quality (PADQ) is a new packet defined in 264 this specification. An Access Concentrator or Host may send an 265 optional PADQ at any time to query or report link quality metrics. 267 When transmitting PPP streams over wireless links through radio 268 modems, the quality of the RF link directly affects the throughput. 269 The PPPoE Active Discovery Quality (PADQ) packet can be used by the 270 radio modem to report RF link metrics. The CODE field is set to 0x0C 271 and the SESSION_ID must be set to the unique value generated for 272 this PPPoE session. 274 The PADQ must carry a single Metric Tag TYPE, which contains the 275 following fields: 277 Receive only - is a bit that indicates if the link is bi- 278 directional or receive only. A value of -1- indicates that the 279 link is receive-only. 281 Maximum data rate - is the maximum theoretical data rate, in 282 kilobits per second (kbps), that the Host link is capable of 283 providing. When metrics are reported, the maximum data rate 284 must be reported. 286 Current data rate - is the current data rate, in kilobits per 287 second (kbps), achieved on the Host link. If there is no 288 distinction between maximum data rate and current data rate, 289 current data rate should equal to maximum data rate. 291 Latency - is the transmission delay that a packet encounters as 292 it is transmitted over the Host link. This is reported in 293 absolute delay, milliseconds. If latency can not be calculated, 294 a value of 0 should be reported. 296 Resources - is a percentage, 0-100, representing the amount of 297 remaining or available resources, such as battery power. If 298 resources can not be calculated, a value of 100 should be 299 reported. 301 Relative Link Quality (RLQ) - is a non-dimensional number, 0-100, 302 representing the relative link quality. A value of 100 303 represents a link of the highest quality. If the RLQ can not be 304 calculated, a value of 100 should be reported. 306 The PPPoE Active Discovery Quality (PADQ) packet can be used to 307 query link metrics by setting the PADQ Metric Tag Length to zero. 309 An example packet is shown in Appendix B. 311 5. PPP Session Stage 313 This specification defines the optional use of TLV Tags in the PPP 314 Session Stage The first field following the PPP Session Stage 315 LENGTH must be checked. If the value is equal to the PPP Protocol 316 identifier (0xc021), then normal packet (payload) processing occurs. 317 When the field following the PPP Session Stage LENGTH is not the PPP 318 Protocol identifier (0xc021), a TLV is assumed. In this case, the 319 Tag length is subtracted from the overall payload length. 321 The Credit Tag is the only optional TLV permitted in the PPP Session 322 Stage. The Credit Tag TLV is used to support in-band flow control. 324 A PPP Session Stage packet with Credits is shown in Appendix B. 326 6. Credit Flow Considerations 328 For a given session, credit grants exchanged in the Discovery Stage, 329 PADG-PADC, are referred to as out-of-band. Credit grants exchanged 330 in the PPP Session Stage are referred to as in-band. Credit 331 processing is only applied to the packets transmitted in the PPP 332 Session Stage. 334 Out-of-band credit management is handled by periodic exchange of the 335 PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit 336 (PADC) packets. 338 In-band credit management allows credits to be incrementally granted 339 with each PPP Session Stage packet. These in-band incremental credit 340 grants are not explicitly unacknowledged. They are however reflected 341 in the in-band credit flow from the peer node. This offers the 342 greatest credit granting efficiency when traffic rates are high. 344 Once agreed upon during the Discovery Stage, credit grants are 345 required to transmit packets in the PPP Session Stage. A node must 346 grant credits to its peer, before the peer can transmit packets to 347 the granting node. 349 Credits are granted incrementally in the forward direction. Locally 350 a node manages the credits that it has granted to a peer as well as 351 the credits that a peer has granted to it. 353 Grants received from a peer are added to a local running credit 354 counter. The accumulated credits are decremented with each packet 355 the node transmits to the peer. When the running counter reaches 356 zero, the node stops transmitting packets to the peer. The values 357 of the PADC are not simply an echo of the PADG. They represent 358 the current internal FCN/BCN values of that node. 360 To manage the credits that a node has granted, the node maintains a 361 running counter. With each PPP Session Stage packet received from 362 the peer, the running counter is decremented. When the running 363 counter reaches zero, no additional packets are expected. The node 364 incrementally grants more credits to the peer to maintain packet 365 flow. Packets received when granted credits have been exhausted are 366 discarded. 368 The largest possible credit limit is 0x0ffff. If an incremental 369 credit grant causes the accumulated count to exceed this value, the 370 max value is used. 372 One unit of credit represents 64-bytes, so a grant of 4 credits 373 translates to 256-bytes. 375 7. PADG and PADC Retransmission 377 When a node does not receive a PADC packet in response to a PADG 378 within a specified amount of time, it should transmit a new PADG 379 packet with zero credits, using the same sequence number and 380 double the waiting period. A PADC response with the associated 381 sequence number will indicate if the previously granted credits 382 were accumulated or not. If not, a PADG with credits, with 383 an incremented sequence number, should be transmitted. This 384 process should be repeated until granted credits are properly 385 acknowledged or as many times as desired. 387 When a node does not receive a PADQ metric packet within a specified 388 amount of time, it should resend the PADQ query packet and double 389 the waiting period. This can be repeated as many times as desired. 391 8. Other Considerations 393 A node may autonomously generate PADQ metric packets. The rate of 394 autonomously generate PADQ metric packets may need to be throttled 395 so not to overrun the peer. 397 The sending and receiving of PPPoE control packets are independent 398 of credit counts. For example, a node must always be able to 399 receive a PADG and send a PADC. 401 During normal operation, nodes may disagree about the number of 402 credits. Operational credit mismatches would occur due to packets 403 in transit on the wire. Much larger credit mismatches can occur 404 if there are transmission errors. To correct these larger errors, 405 the BCN fields of the PADG and PADC packets and in-band credit 406 grants from a peer should be used by the receiveing node to set 407 the credit values of its peer. 409 9. IANA Considerations 411 At the time of publication, the IANA considerations were being 412 covered by draft-arberg-pppoe-iana, a work in progress. 414 10. Security Considerations 416 This memo defines a mechanism for adding flow control to the 417 existing PPP Over Ethernet (PPPoE) sessions. These extensions 418 are subsequent to the existing PPPoE security mechanisms as 419 described in RFC 2516 [2]. It is required that the Service 420 Tag and Session ID always be validated prior to processing 421 credits. 423 11. Appendix A: Tag Values 425 Feature Tag_Types and Tag_Values 427 0x0106 Credits 429 This tag contains the Forward Credit Notification (FCN) and the 430 Backward Credit Notification (BCN). The Credit Tag TLV is 431 OPTIONAL with the PADR, PADS and the PPPoE data payload packet 432 (ETHER_TYPE=8864). 434 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Tag Type = 0x0106 | Tag Length=0x04 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | FCN | BCN | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 0x0107 Metrics 443 This tag is used to report the link quality and performance. The 444 Metrics Tag TLV contains the Receive Only indicator, Resource 445 status, Latency, Relative Link Quality (RLQ), Current data rate 446 and Maximum data rate. The Metrics TLV is required by the PADQ 447 packet. 449 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Tag Type = 0x0107 | Tag Length=0x0A | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved |R| RLQ | Resource | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Latency (MS) | Current Datarate (kbps) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Maximum Datarate (kbps) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 0x0108 Sequence Number 463 This tag is used to carry a unique 16-bit sequence number in 464 order to identify a specific request and the associated response. 465 The sequence number should be initialized to zero and incremented 466 by one for each new request. For re-transmitted packets, the 467 same sequence number that was used in the previous packet 468 transmission is repeated. The PADG and PADC packets require 469 the Sequence Number Tag. 471 For example, the sequence number sent in the PADG request is 472 echoed in the PADC response. This ties a specific PADC response 473 to a specific PADG request. 475 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Tag Type = 0x0108 | Tag Length=0x02 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Sequence Number | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 11. Appendix B: Example Message Formats 485 A PADR packet with OPTIONAL Credit Tag Type 0x0106: 487 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Access_Concentrator_mac_addr | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Host_mac_addr (cont) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | SESSION_ID = 0x1234 | LENGTH = 0x0C | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Tag Type = 0x0101 | Tag Length=0x00 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Tag Type = 0x0106 | Tag Length=0x04 | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | FCN | BCN | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 A PADS packet with OPTIONAL Credit Tag Type 0x0106: 508 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 | Tag Type = 0x0101 | Tag Length=0x00 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Tag Type = 0x0106 | Tag Length=0x04 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | FCN | BCN | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 A PADG packet with Credit Tag Type 0x0106: 529 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Destination_mac_addr | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Destination_mac_addr(c) | Source_mac_addr | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Source mac_addr (cont) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0A | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | SESSION_ID = 0x1234 | LENGTH = 0x0E | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Tag Type = 0x0108 | Tag Length=0x02 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Sequence Number | Tag Type = 0x0106 | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Tag Length=0x04 | FCN | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | BCN | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 A PADC packet with Credit Tag Type 0x0106: 552 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Destination_mac_addr | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Destination_mac_addr(c) | Source_mac_addr | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Source mac_addr (cont) | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0B | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | SESSION_ID = 0x1234 | LENGTH = 0x0E | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Tag Type = 0x0108 | Tag Length=0x02 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Sequence Number | Tag Type = 0x0106 | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Tag Length=0x04 | FCN | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | BCN | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 A PADQ packet to query for the link metrics: This is indicated by 574 the Metric Tag Length=0. 576 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Access_Concentrator_mac_addr | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Host_mac_addr (cont) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | SESSION_ID = 0x1234 | LENGTH = 0x08 | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Tag Type = 0x0101 | Tag Length=0x00 | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Tag Type = 0x0107 | Tag Length=0x00 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 A PADQ packet with Metric Tag Type 0x0107: 595 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Access_Concentrator_mac_addr | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Host_mac_addr (cont) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | SESSION_ID = 0x1234 | LENGTH = 0x12 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Tag Type = 0x0101 | Tag Length=0x00 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Tag Type = 0x0107 | Tag Length=0x0A | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Reserved |R| RLQ | Resource | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Latency (MS) | Current Datarate (kbps) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Maximum Datarate (kbps) | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 A PPP LCP packet with optional Credit Tag Type 0x0106: 619 While the PPP protocol value is shown (0xc021), the PPP payload is 620 left to the reader. This is a packet from the Host to the Access 621 Concentrator. 623 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Access_Concentrator_mac_addr | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Host_mac_addr (cont) | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | SESSION_ID = 0x1234 | LENGTH = 0x???? | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Tag Type = 0x0106 | Tag Length=0x04 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | FCN | BCN | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | PPP PROTOCOL = 0xc021 | PPP payload ~ 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 12. Acknowledgements 645 The authors would like to acknowledge the influence and 646 contributions from Billy Moon, Fred Baker, Stan Ratliff 647 and Ed Paradise. 649 13. Normative References 651 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 652 51, RFC 1661, July 1994 654 [2] Mamakos L., et. al., "A Method for Transmitting PPP Over 655 Ethernet (PPPoE)", RFC 2516, February 1999. 657 Authors' Address 659 Bo Berry 660 Cisco 661 170 West Tasman Drive 662 San Jose, CA 95134 663 USA 664 email: bberry@cisco.com 666 Howard Holgate 667 Cisco 668 170 West Tasman Drive 669 San Jose, CA 95134 670 USA 671 email: hholgate@cisco.com 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of 676 any Intellectual Property Rights or other rights that might be 677 claimed to pertain to the implementation or use of the technology 678 under such rights described in this document or the extent to 679 which any license might or might not be available; nor does it 680 represent that it has made any independent effort to identify 681 any such rights. Information on the procedures with respect to 682 rights in RFC documents can be found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the 687 use of such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR 689 repository at http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention 692 any copyrights, patents or patent applications, or other 693 proprietary rights that may cover technology that may be required 694 to implement this standard. Please address the information to 695 the IETF at ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided 700 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 701 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 702 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 703 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 704 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 705 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 706 OR FITNESS FOR A PARTICULAR PURPOSE. 708 Copyright Statement 710 Copyright (C) The Internet Society (2006). This document is 711 subject to the rights, licenses and restrictions contained in 712 BCP 78, and except as set forth therein, the authors retain 713 all their rights. 715 Acknowledgment 717 Funding for the RFC Editor function is currently provided by the 718 Internet Society.