draft-ietf-manet-credit-window-02.txt   draft-ietf-manet-credit-window-03.txt 
Mobile Ad hoc Networks Working Group S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Internet-Draft VT iDirect Internet-Draft VT iDirect
Intended status: Standards Track March 8, 2016 Intended status: Standards Track March 21, 2016
Expires: September 9, 2016 Expires: September 22, 2016
Credit Windowing extension for DLEP Credit Windowing extension for DLEP
draft-ietf-manet-credit-window-02 draft-ietf-manet-credit-window-03
Abstract Abstract
This draft describes an extension to the DLEP protocol to provide a This draft describes an extension to the DLEP protocol to provide a
credit-windowing scheme analogous to that in RFC5578 for destination- credit-windowing scheme analogous to that in RFC5578 for destination-
specific flow control. specific flow control.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. DLEP Messages for Credit-Window Extension . . . . . . . . . . 4 5. DLEP Messages for Credit-Window Extension . . . . . . . . . . 4
6. DLEP Status Codes for Credit-Window Extension . . . . . . . . 4 6. DLEP Status Codes for Credit-Window Extension . . . . . . . . 5
7. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5 7. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5
7.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 5 7.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 5
7.2. DLEP Destination Up Response Message . . . . . . . . . . 5 7.2. DLEP Destination Announce Message . . . . . . . . . . . . 6
7.3. DLEP Destination Update Message . . . . . . . . . . . . . 6 7.3. DLEP Destination Up Response Message . . . . . . . . . . 6
7.4. DLEP Link Characteristics Request Message . . . . . . . . 6 7.4. DLEP Destination Announce Response Message . . . . . . . 6
8. Credit Window Data Item Definitions . . . . . . . . . . . . . 6 7.5. DLEP Destination Update Message . . . . . . . . . . . . . 7
8.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 6 7.6. DLEP Link Characteristics Request Message . . . . . . . . 7
8.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7 8. Credit Window Data Item Definitions . . . . . . . . . . . . . 7
8.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 9 8.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.2. Credit Window Status . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 10
10.1. Registrations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Registrations . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In the world of radio-based networking, there are modems that need In the world of radio-based networking, there are modems that need
fine-grained flow control over traffic ingressing from a LAN fine-grained flow control over traffic ingressing from a LAN
connection, bound for transmission over the RF. The need for such connection, bound for transmission over the RF. The need for such
fine-grained control can exist for multiple reasons. For example, fine-grained control can exist for multiple reasons. For example,
radio devices are typically connected to the network by Ethernet. radio devices are typically connected to the network by Ethernet.
The capacity of an Ethernet link is normally far superior to that of The capacity of an Ethernet link is normally far superior to that of
the RF, leading to the possibility of overruns and dropped traffic. the RF, leading to the possibility of overruns and dropped traffic.
skipping to change at page 3, line 22 skipping to change at page 3, line 30
document identifies these windows as the 'Modem Receive Window', or document identifies these windows as the 'Modem Receive Window', or
MRW, and the 'Router Receive Window', or RRW. The responsibility of MRW, and the 'Router Receive Window', or RRW. The responsibility of
granting credits lies with the receiver on a window - that is, on the granting credits lies with the receiver on a window - that is, on the
MRW, the modem is responsible for granting credits to the router, MRW, the modem is responsible for granting credits to the router,
allowing it (the router) to send data plane traffic to the modem. allowing it (the router) to send data plane traffic to the modem.
Likewise, the router is responsible for granting credits on the RRW, Likewise, the router is responsible for granting credits on the RRW,
which allows the modem to send data plane traffic to the router. which allows the modem to send data plane traffic to the router.
Credits represent the number of data plane octets, or an increment in Credits represent the number of data plane octets, or an increment in
the number of data plane octets, that can be sent on a given window the number of data plane octets, that can be sent on a given window
at the at the MAC layer to the receiver.
MAC layer to the receiver.
3. Terminology 3. Terminology
In general, the draft uses the same terminology as specified in the In general, the draft uses the same terminology as specified in the
core DLEP draft [DLEP]. In addition, the draft uses the following core DLEP draft [DLEP]. In addition, the draft uses the following
terms: terms:
o Modem Receive Window, or MRW. The MRW represents a logical, o Modem Receive Window, or MRW. The MRW represents a logical,
unidirectional window for traffic flowing from the router to the unidirectional window for traffic flowing from the router to the
modem. modem.
skipping to change at page 4, line 6 skipping to change at page 4, line 13
Initialization Response messages. Initialization Response messages.
Credits are managed on a destination-specific basis - separate credit Credits are managed on a destination-specific basis - separate credit
counts MUST be maintained for each destination requiring the service. counts MUST be maintained for each destination requiring the service.
Credits MUST NOT be applied to the DLEP session that exists between Credits MUST NOT be applied to the DLEP session that exists between
routers and modems; they are applied only to the data plane traffic. routers and modems; they are applied only to the data plane traffic.
There are no default values for either the initial credit window or There are no default values for either the initial credit window or
the credit increments. the credit increments.
When DLEP peers desire to employ the credit-windowing extension, the When DLEP peers desire to employ the credit-windowing extension, the
peer originating the Destination Up message MUST supply a Credit peer originating the Destination Up or Destination Announce message
Grant data item with an initial, non-zero value as the increment of MUST supply a Credit Grant data item with an initial, non-zero value
the window the originator controls (i.e., the MRW, or RRW). as the increment of the window the originator controls (i.e., the
MRW, or RRW).
When receiving a Credit Grant data item on a Destination Up message, When receiving a Credit Grant data item on a Destination Up or
the receiver MUST take one of the following actions: Destination Announce message, the receiver MUST take one of the
following actions:
1. Reject the use of credits for this destination, via the 1. Reject the use of credits for this destination, via the
Destination Up Response message containing a Status data item Destination Up Response or Destination Announce Response message
with a status code of 'Credit Use Rejected', or containing a Status data item with a status code of 'Credit Use
Rejected', or
2. Initialize the appropriate window value of zero, then apply the 2. Initialize the appropriate window value of zero, then apply the
increment specified in the Credit Grant data item. increment specified in the Credit Grant data item.
If the initialization completes successfully, the receiver MUST If the initialization completes successfully, the receiver MUST
respond to the Destination Up message with a Destination Up Response respond to the Destination Up/Destination Announce message with a
message that contains a Credit Grant data item, initializing its response message that contains a Credit Grant data item, initializing
receive window. its receive window.
Data plane traffic would then flow between the DLEP peers, with said Data plane traffic would then flow between the DLEP peers, with said
peers accounting for the traffic sent/received by decrementing the peers accounting for the traffic sent/received by decrementing the
appropriate credit counts. appropriate credit counts.
The number of credits needed for a given transmission is the length The number of credits needed for a given transmission is the length
of the data portion of the packet at the MAC layer. When sending of the data portion of the packet at the MAC layer. When sending
data to a credit enabled peer, the sender MUST decrement the data to a credit enabled peer, the sender MUST decrement the
appropriate window by the size of the data being sent, prior to appropriate window by the size of the data being sent, prior to
encapsulation at the MAC layer. When traffic is received, the encapsulation at the MAC layer. When traffic is received, the
skipping to change at page 5, line 41 skipping to change at page 6, line 5
If use of credits is required for the destination, then the If use of credits is required for the destination, then the
Destination Up message MUST contain one Credit Grant (Section 8.1) Destination Up message MUST contain one Credit Grant (Section 8.1)
data item. The value of the credit increment is at the discretion of data item. The value of the credit increment is at the discretion of
the implementation. The receiver of the Destination Up message MUST the implementation. The receiver of the Destination Up message MUST
use the value in Credit Grant as the initial value for the use the value in Credit Grant as the initial value for the
appropriate window. appropriate window.
If the Destination Up message does not contain the Credit Grant data If the Destination Up message does not contain the Credit Grant data
item, credits MUST NOT be used for that destination. item, credits MUST NOT be used for that destination.
7.2. DLEP Destination Up Response Message 7.2. DLEP Destination Announce Message
If use of credits is required for the destination, then the
Destination Announce message MUST contain one Credit Grant
(Section 8.1) data item. The value of the credit increment is at the
discretion of the implementation. The receiver of the Destination
Announce message MUST use the value in Credit Grant as the initial
value for the appropriate window.
If the Destination Announce message does not contain the Credit Grant
data item, credits MUST NOT be used for that destination.
7.3. DLEP Destination Up Response Message
If the corresponding Destination Up message contained a Credit Grant If the corresponding Destination Up message contained a Credit Grant
(Section 8.1) data item, the Destination Up Response message MUST (Section 8.1) data item, the Destination Up Response message MUST
also contain a Credit Grant (Section 8.1) data item. also contain a Credit Grant (Section 8.1) data item.
Likewise, if the corresponding Destination Up message did not contain Likewise, if the corresponding Destination Up message did not contain
a Credit Grant (Section 8.1) data item, the Destination Up Response a Credit Grant (Section 8.1) data item, the Destination Up Response
message MUST NOT contain a Credit Grant (Section 8.1) data item. message MUST NOT contain a Credit Grant (Section 8.1) data item.
The receiver of Destination Up Response MUST use the received Credit The receiver of Destination Up Response MUST use the received Credit
Grant value to initialize the appropriate window (e.g., the MRW value Grant value to initialize the appropriate window (e.g., the MRW value
for routers, the RRW value for modems). for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Up and of credit window data items between the DLEP Destination Up and
Destination Up Response messages, the implementation detecting the Destination Up Response messages, the implementation detecting the
mismatch MUST terminate the session by issuing a Peer Termination mismatch MUST terminate the session by issuing a Peer Termination
message with a status code of 'Credit Wondow Out of Sync', and message with a status code of 'Credit Window Out of Sync', and
transition to the Session Termination state. transition to the Session Termination state.
7.3. DLEP Destination Update Message 7.4. DLEP Destination Announce Response Message
If the corresponding Destination Up message contained the Credit If the corresponding Destination Announce message contained a Credit
Grant data item, the Destination Update message MAY contain one of Grant (Section 8.1) data item, the Destination Announce Response
each of the following data items: message MUST also contain a Credit Grant (Section 8.1) data item.
Likewise, if the corresponding Destination Announce message did not
contain a Credit Grant (Section 8.1) data item, the Destination
Announce Response message MUST NOT contain a Credit Grant
(Section 8.1) data item.
The receiver of Destination Announce Response MUST use the received
Credit Grant value to initialize the appropriate window (e.g., the
MRW value for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Announce and
Destination Announce Response messages, the implementation detecting
the mismatch MUST terminate the session by issuing a Peer Termination
message with a status code of 'Credit Window Out of Sync', and
transition to the Session Termination state.
7.5. DLEP Destination Update Message
If the corresponding Destination Up or Destination Announce message
contained the Credit Grant data item, the Destination Update message
MAY contain one of each of the following data items:
o Credit Grant (Section 8.1) o Credit Grant (Section 8.1)
o Credit Window Status (Section 8.2) o Credit Window Status (Section 8.2)
o Credit Request (Section 8.3)
DLEP peers supporting the extension MAY format and send a DLEP DLEP peers supporting the extension MAY format and send a DLEP
Destination Update message solely for the purposes of maintaining the Destination Update message solely for the purposes of maintaining the
credit windows. In cases where a peer already has information credit windows. In cases where a peer already has information
requiring a Destination Update message, (e.g., a change in Latency on requiring a Destination Update message, (e.g., a change in Latency on
the link), the credit data items MAY be included in addition to that the link), the credit data items MAY be included in addition to that
information. information.
7.4. DLEP Link Characteristics Request Message 7.6. DLEP Link Characteristics Request Message
If the corresponding Destination Up message contained the credit If the corresponding Destination Up or Destination Announce message
Grant data item, the Link Characteristics Request message MAY contain contained the credit Grant data item, the Link Characteristics
the following data item: Request message MAY contain the following data item:
o Credit Request (Section 8.3) o Credit Request (Section 8.3)
DLEP peers supporting the extension MAY format and send a DLEP Link DLEP peers supporting the extension MAY format and send a DLEP Link
Characteristics Request message solely for the purposes of Characteristics Request message solely for the purposes of
maintaining the credit windows. In cases where a peer already has maintaining the credit windows. In cases where a peer already has
information requiring a Link Characteristics Request message, the information requiring a Link Characteristics Request message, the
Credit Request data MAY be included in addition to that information. Credit Request data MAY be included in addition to that information.
8. Credit Window Data Item Definitions 8. Credit Window Data Item Definitions
8.1. Credit Grant 8.1. Credit Grant
The Credit Grant data item is sent from a DLEP participant to grant The Credit Grant data item is sent from a DLEP participant to grant
an increment to credits on a window. The Credit Grant data item MAY an increment to credits on a window. The Credit Grant data item MAY
appear in the DLEP Destination Up and Destination Update messages. appear in the DLEP Destination Up, Destination Announce, and
The value in a Credit Grant data item represents an increment to be Destination Update messages. The value in a Credit Grant data item
added to any existing credits available on the window. Upon represents an increment to be added to any existing credits available
successful receipt and processing of a Credit Grant data item, the on the window. Upon successful receipt and processing of a Credit
receiver MUST respond with a message containing a Credit Window Grant data item, the receiver MUST respond with a message containing
Status data item to report the updated aggregate values for a Credit Window Status data item to report the updated aggregate
synchronization purposes, and if initializing a new credit window, values for synchronization purposes, and if initializing a new credit
granting initial credits. window, granting initial credits.
The Credit Grant data item contains the following fields: The Credit Grant data item contains the following fields:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length | | Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | | Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 8 skipping to change at page 10, line 8
the current number of credits, in octets, available on the Modem the current number of credits, in octets, available on the Modem
Receive Window, for the destination referred to by the message. Receive Window, for the destination referred to by the message.
Router Receive Window Value: A 64-bit unsigned integer, indicating Router Receive Window Value: A 64-bit unsigned integer, indicating
the current number of credits, in octets, available on the Router the current number of credits, in octets, available on the Router
Receive Window, for the destination referred to by the message. Receive Window, for the destination referred to by the message.
8.3. Credit Request 8.3. Credit Request
The Credit Request data item MAY be sent from either DLEP The Credit Request data item MAY be sent from either DLEP
participant, as a data item in a DLEP Destination Update message, to participant, as a data item in a DLEP Destination Update message, or
indicate the desire for the partner to grant additional credits in a Link Characteristics Request message, to indicate the desire for
order for data transfer to proceed on the session. If the the partner to grant additional credits in order for data transfer to
corresponding DLEP Destination Up message for this session did not proceed on the session. If the corresponding DLEP Destination Up or
contain a Credit Grant data item, indicating that credits are to be Destination Announce message for this session did not contain a
used on the session, then receipt of the Credit Request data item Credit Grant data item, indicating that credits are to be used on the
MUST be considered as an error by the receiver, requiring termination session, then receipt of the Credit Request data item MUST be
of the DLEP peer session. considered as an error by the receiver, requiring termination of the
DLEP peer session.
The Credit Request data item contains the following fields: The Credit Request data item contains the following fields:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length | | Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
skipping to change at page 9, line 48 skipping to change at page 10, line 49
10. IANA Considerations 10. IANA Considerations
This section specifies requests to IANA. This section specifies requests to IANA.
10.1. Registrations 10.1. Registrations
This specification defines three (3) new entries in the repository This specification defines three (3) new entries in the repository
entitled "Data Item Type Values for the Dynamic Link Event Protocol entitled "Data Item Type Values for the Dynamic Link Event Protocol
(DLEP)". Assignments from that registry are requested for: (DLEP)". Assignments from that registry are requested for:
o Credit Grant o Credit Request o Credit Window Status o Credit Grant
o Credit Request
o Credit Window Status
The specification also defines an extension to the DLEP protocol. An The specification also defines an extension to the DLEP protocol. An
assignment from the repository entitled "Extension Type Values for assignment from the repository entitled "Extension Type Values for
the Dynamic Link Event Protocol (DLEP)" is requested for: the Dynamic Link Event Protocol (DLEP)" is requested for:
o Credit Windowing o Credit Windowing
In addition, the specification defines two (2) new DLEP status codes. In addition, the specification defines two (2) new DLEP status codes.
Assignments from the repository entitled "Status Code Values for the Assignments from the repository entitled "Status Code Values for the
Dynamic Link Event Protocol (DLEP)" are requested for: Dynamic Link Event Protocol (DLEP)" are requested for:
o Credit Window Out of Sync o Credit Use Rejected o Credit Window Out of Sync
o Credit Use Rejected
11. Acknowledgements 11. Acknowledgements
The author would like to acknowledge and thank the members of the The author would like to acknowledge and thank the members of the
MANET working group, who have provided valuable insight. MANET working group, who have provided valuable insight.
Specifically, the author would like to thank Lou Berger, Justin Dean, Specifically, the author would like to thank Lou Berger, David
Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell,
Satterwhite. Shawn Jury, and Darryl Satterwhite.
12. References 12. References
12.1. Normative References 12.1. Normative References
[DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- Berry, "Dynamic Link Exchange Protocol (DLEP)", draft-
ietf-manet-dlep-20 IETF draft, February 2015. ietf-manet-dlep-21 IETF draft, March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References 12.2. Informative References
[RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and
M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
 End of changes. 24 change blocks. 
65 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/