draft-ietf-manet-credit-window-01.txt   draft-ietf-manet-credit-window-02.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 February 4, 2016 Intended status: Standards Track March 8, 2016
Expires: August 7, 2016 Expires: September 9, 2016
Credit Windowing extension for DLEP Credit Windowing extension for DLEP
draft-ietf-manet-credit-window-01 draft-ietf-manet-credit-window-02
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 August 7, 2016. This Internet-Draft will expire on September 9, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . 4
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 Up Response Message . . . . . . . . . . 5
7.3. DLEP Destination Update Message . . . . . . . . . . . . . 6 7.3. DLEP Destination Update Message . . . . . . . . . . . . . 6
7.4. DLEP Link Characteristics Request Message . . . . . . . . 6 7.4. DLEP Link Characteristics Request Message . . . . . . . . 6
8. Credit Window Data Item Definitions . . . . . . . . . . . . . 6 8. Credit Window Data Item Definitions . . . . . . . . . . . . . 6
8.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7 8.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7
8.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 9 8.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10.1. Registrations . . . . . . . . . . . . . . . . . . . . . 10 10.1. Registrations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 22
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 OSI Layer 2 to the receiver. at the
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 15 skipping to change at page 4, line 15
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 message MUST supply a Credit
Grant data item with an initial, non-zero value as the increment of Grant data item with an initial, non-zero value as the increment of
the window the originator controls (i.e., the MRW, or RRW). 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 message,
the receiver MUST take one of the following actions: 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 message containing a Status data item
with a status code of 'Request Denied'. (See status codes in with a status code of 'Credit Use Rejected', or
[DLEP]), 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 message with a Destination Up Response
message that contains a Credit Grant data item, initializing its message that contains a Credit Grant data item, initializing its
receive window. 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 OSI Layer 2. When sending data of the data portion of the packet at the MAC layer. When sending
to a credit enabled peer, the sender MUST decrement the appropriate data to a credit enabled peer, the sender MUST decrement the
window by the size of the data being sent, prior to encapsulation at appropriate window by the size of the data being sent, prior to
OSI Layer 2. When traffic is received, the receiver MUST decrement encapsulation at the MAC layer. When traffic is received, the
its own window after decapsulation at OSI Layer 2. receiver MUST decrement its own window after decapsulation at the MAC
layer.
When the number of available credits to the destination reaches 0, When the number of available credits to the destination reaches 0,
the sender MUST stop sending data plane traffic to the destination, the sender MUST stop sending data plane traffic to the destination,
until additional credits are granted by the receiver. until additional credits are granted by the receiver.
5. DLEP Messages for Credit-Window Extension 5. DLEP Messages for Credit-Window Extension
The credit-windowing extension does not introduce any additional DLEP The credit-windowing extension does not introduce any additional DLEP
signals or messages. signals or messages.
6. DLEP Status Codes for Credit-Window Extension 6. DLEP Status Codes for Credit-Window Extension
The credit-windowing extension introduces one additional DLEP status The credit-windowing extension introduces two additional DLEP status
code: code:
+------------+--------+-------------+-------------------------------+ +--------------+----------+------------+----------------------------+
| Status | Value | Failure | Reason | | Status Code | Value | Failure | Reason |
| Code | | Mode | | | | | Mode | |
+------------+--------+-------------+-------------------------------+ +--------------+----------+------------+----------------------------+
| Credit | TBD | Terminate | Credit counts are out-of-sync | | Credit | TBD | Continue | Credit counts are out-of- |
| Window Out | | | between sender and receiver | | Window Out | | | sync between sender and |
| of Sync | | | on the destination. | | of Sync | | | receiver on the |
+------------+--------+-------------+-------------------------------+ | | | | destination. |
| Credit Use | TBD | Continue | Credit counts cannot be |
| Rejected | | | used for the destination. |
+--------------+----------+------------+----------------------------+
7. DLEP Data Items for Credit-Window Extension 7. DLEP Data Items for Credit-Window Extension
The extension introduces 3 DLEP data items: The extension introduces 3 DLEP data items:
+------------+------------------------------------------------------+ +------------+-------------------------------------+
| Type Code | Description | | Type Code | Description |
+------------+------------------------------------------------------+ +------------+-------------------------------------+
| TBD | Credit Grant (Section 8.1) | | TBD | Credit Grant (Section 8.1) |
| TBD | Credit Window Status (Section 8.2) | | TBD | Credit Window Status (Section 8.2) |
| TBD | Credit Request (Section 8.3) | | TBD | Credit Request (Section 8.3) |
+------------+------------------------------------------------------+ +------------+-------------------------------------+
Descriptions of the data items are included below. The credit- Descriptions of the data items are included below. The credit-
windowing data items are inserted into DLEP messages as follows: windowing data items are inserted into DLEP messages as follows:
7.1. DLEP Destination Up Message 7.1. DLEP Destination Up Message
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
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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 'XXXX', and transition to the Session message with a status code of 'Credit Wondow Out of Sync', and
Termination state. transition to the Session Termination state.
7.3. DLEP Destination Update Message 7.3. DLEP Destination Update Message
If the corresponding Destination Up message contained the Credit If the corresponding Destination Up message contained the Credit
Grant data item, the Destination Update message MAY contain one of Grant data item, the Destination Update message MAY contain one of
each of the following data items: 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)
skipping to change at page 7, line 33 skipping to change at page 7, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | | Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | | Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 8 Length: 8
Reserved: A 64-bit unsigned integer representing the additional Credit Increment: A 64-bit unsigned integer representing the
credits to be assigned to the credit window. additional credits, in octets, to be assigned to the credit
window.
Since credits can only be granted by the receiver on a window, the Since credits can only be granted by the receiver on a window, the
applicable credit window (either the MRW or the RRW) is derived from applicable credit window (either the MRW or the RRW) is derived from
the sender of the grant. The Credit Increment MUST NOT cause the the sender of the grant. The Credit Increment MUST NOT cause the
window to overflow; if this condition occurs, implementations MUST window to overflow; if this condition occurs, implementations MUST
set the credit window to the maximum value contained in a 64-bit set the credit window to the maximum value contained in a 64-bit
quantity. quantity.
8.2. Credit Window Status 8.2. Credit Window Status
When credits are used, DLEP session peers MAY use the Credit Window During normal operation, DLEP session peers may disagree about the
Status data item to maintain synchronization of credit counts. This number of available credits. Operational credit mismatches can occur
data item is informational only; it is used to inform the receiving due to packets in transit on the wire. DLEP session peers MAY use
peer of the current credit counts for both the MRW and RRW, from the the Credit Window Status data item to maintain synchronization of
perspective of the sender. credit counts. This data item is informational only; it is used to
inform the receiving peer of the current credit counts for both the
MRW and RRW, from the perspective of the sender.
Upon receipt of a Credit Window Status data item, an implementation Upon receipt of a Credit Window Status data item, an implementation
SHOULD compare its own credit counts with that of the originator. If SHOULD compare its own credit counts with that of the originator. If
the receiver of Credit Window Status detects that the local credit the receiver of Credit Window Status detects that the local credit
counts are not synchronized with the originator, the receiving counts are not synchronized with the originator, the receiving
implementation MAY either 1. Attempt resynchronization using Credit implementation MAY either: o Attempt resynchronization using an
Grant, if applicable, or 2. Issue a DLEP Destination Down message, additional Credit Grant, if applicable, or o Issue a DLEP Destination
to clear credit counts on the session. Down message, to clear credit counts on the session.
Implementations issuing Destinaton Down MUST supply a DLEP Status Implementations issuing Destinaton Down MUST supply a DLEP Status
item, with the status code of 'Credit Window Out of Sync', as defined item, with the status code of 'Credit Window Out of Sync', as defined
in this document. in this document.
If a DLEP message contains both the Credit Grant (Section 8.1) data If a DLEP message contains both the Credit Grant (Section 8.1) data
item and the Credit Window Status (Section 8.2) data item, item and the Credit Window Status (Section 8.2) data item,
implementations MUST first apply the Credit Grant (Section 8.1) data implementations MUST first apply the Credit Grant (Section 8.1) data
item before comparing the credit counts contained in Credit Window item before comparing the credit counts contained in Credit Window
Status (Section 8.2). Status (Section 8.2).
skipping to change at page 8, line 49 skipping to change at page 8, line 46
| Router Receive Window Value : | Router Receive Window Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Router Receive Window Value | : Router Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 16 Length: 16
Modem Receive Window Value: A 64-bit unsigned integer, indicating Modem Receive Window Value: A 64-bit unsigned integer, indicating
the current number of credits available on the Modem Receive the current number of credits, in octets, available on the Modem
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 available on the Router Receive the current number of credits, in octets, available on the Router
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, to
indicate the desire for the partner to grant additional credits in indicate the desire for the partner to grant additional credits in
order for data transfer to proceed on the session. If the order for data transfer to proceed on the session. If the
corresponding DLEP Destination Up message for this session did not corresponding DLEP Destination Up message for this session did not
contain a Credit Grant data item, indicating that credits are to be contain a Credit Grant data item, indicating that credits are to be
used on the session, then receipt of the Credit Request data item used on the session, then receipt of the Credit Request data item
skipping to change at page 9, line 36 skipping to change at page 9, line 32
| Data Item Type | Length | | Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 0 Length: 0
9. Security Considerations 9. Security Considerations
The extension introduces a mechanism for destination-specific flow The extension introduces a mechanism for destination-specific flow
control between a router and modem supporting the DLEP protocol. In control between a router and modem supporting the DLEP protocol. The
cases where an adversary can access the network segment on which the extension does not introduce any additional threats above those
router and modem are attached, the following threats are possibe: documented in [DLEP].
The mitigation strategy documented in that document is sufficient to
1. An attacker could act as either modem or router, establishing a secure operation of this extension.
session with the DLEP peer. This session could be used to flood
the session with various requests, amounting to a denial of
service attack. In these environments, implementations MUST
employ [TLS], as the certificate verification in that protocol
will verify the identity of devices attempting to connect.
2. An attacker could mount a Man In The Middle (MITM) attack,
altering the credit values supplied by the DLEP peers. Such an
alteration could cause either (a) a cessation of traffic (by
setting credit values to 0), or (b) overruns and drops (e.g., by
setting credit values to the maximum value of a 64-bit integer).
In these environments, implementations MUST employ [TLS],
leveraging the message protection mechanisms in that protocol.
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 data items for DLEP. This specification defines three (3) new entries in the repository
Assignments from the DLEP data item registry are requested for: entitled "Data Item Type Values for the Dynamic Link Event Protocol
(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 defined an extension to the DLEP protocol. An The specification also defines an extension to the DLEP protocol. An
assignment from the DLEP extension registry is requested for 'Credit assignment from the repository entitled "Extension Type Values for
Windowing'. the Dynamic Link Event Protocol (DLEP)" is requested for:
In addition, the specification defines an additional DLEP status o Credit Windowing
code. An assignment from the DLEP registry for status codes is
requested for 'Credit Window Out of Sync'. In addition, the specification defines two (2) new DLEP status codes.
Assignments from the repository entitled "Status Code Values for the
Dynamic Link Event Protocol (DLEP)" are requested for:
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, Justin Dean,
Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl
Satterwhite. 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-18 IETF draft, February 2015. ietf-manet-dlep-20 IETF draft, February 2015.
[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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
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
Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578,
February 2010, <http://www.rfc-editor.org/info/rfc5578>. February 2010, <http://www.rfc-editor.org/info/rfc5578>.
Author's Address Author's Address
Stan Ratliff Stan Ratliff
 End of changes. 25 change blocks. 
84 lines changed or deleted 77 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/