Internet DRAFT - draft-dalela-dlep-flow-control
draft-dalela-dlep-flow-control
Mobile Ad Hoc Networks Working Group A. Dalela
Internet Draft A. Parashar
Intended status: Standards Track S.L. Ananth
Expires: September 2016 Cisco Systems
March 15, 2016
Flow Control Extension for DLEP
draft-dalela-dlep-flow-control-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 15, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Dalela Expires September 15, 2016 [Page 1]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
There is a need for a mechanism to flow control the data plane
traffic between the router and the modem. This draft extends DLEP
protocol to provide Ethernet based flow control schemes.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Overview.......................................................4
5. Priority-based Flow Control....................................5
5.1. Operation.................................................5
5.2. PFC Data Item Definitions.................................6
5.3. Limitations...............................................6
6. PFC using CoS and MAC for DLEP flow control....................6
6.1. PFC PAUSE frame...........................................7
7. PFC using the VLAN ID for DLEP flow control....................8
7.1. Operation.................................................8
7.2. Tagged PFC PAUSE frame....................................9
8. Security Considerations.......................................10
9. IANA Considerations...........................................10
9.1. Registrations............................................10
10. References...................................................10
10.1. Normative References....................................10
11. Acknowledgments..............................................11
1. Introduction
The Dynamic Link Exchange protocol [DLEP] runs between a router and
its attached modem devices, allowing the modem to communicate radio
link characteristics, and radio network convergence events as they
change. Flow control in DLEP is an optional extension. One possible
extension is [CREDIT].
Dalela Expires September 15, 2016 [Page 2]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
This draft describes an extension to DLEP protocol, allowing for PFC
based flow control schemes to be implemented on a destination-by-
destination basis.
1. Priority Flow Control (PFC) that is, [802.1Qbb]
2. PFC in conjunction with MAC address
3. PFC in conjunction with VLAN tagging.
This draft describes an extension to DLEP protocol and doesn't
attempt to suggest or make any updates/modifications to any other
protocol or standard mentioned in the draft.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these keywords.
3. Terminology
Peer: A router and the modem with which it has established a DLEP
session are referred to as peers.
Neighbor: A router which is accessible via a peer's RF link.
CoS: This is a 3-bit 802.1p Class of Service value in an Ethernet
frame defined in the IEEE 802.1q standard. Up to 8 different traffic
classes are supported.
Traffic Class: A stream of traffic characterized by 802.1p Class-of-
Service or DSCP.
Dalela Expires September 15, 2016 [Page 3]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
HWM/LWM: Higher and lower water marks are the thresholds set against
the buffer occupancy levels at which traffic should be
stopped/started via IEEE 802.1Qbb pause frames.
4. Overview
This protocol extension to DLEP provides a PFC based flow control
scheme. Here, we present an overview of PFC based flow control
mechanisms which offloads the flow control into the Ethernet layer,
rather than keeping them within DLEP.
In the PFC based schemes, data plane traffic flowing between two
devices is being controlled by the buffer occupancy level and the
thresholds set against the receive buffers per traffic class level.
On sensing potential of congestion for CoS based traffic class it
sends a PFC PAUSE frame with a bitmap of all traffic classes to the
link partner, indicating which traffic classes are to be paused.
TRANSMIT-OFF/TRANSMIT-ON pair can be sent for each individual
priority based flow, while all other flows can continue transmitting
and receiving data. As the congestion alleviates, another PFC PAUSE
frame is sent so as to enable link partner to start transmitting the
traffic for the given traffic class.
In PFC, the sender of the PFC PAUSE frame assigns separate logical
queues for each traffic class. The sender SHOULD manage and account
buffer occupancy levels and HWM, LWM thresholds for each logical
queue.
This schemes uses IEEE 802.1Qbb PAUSE semantics and uses it in
conjunction with L2 constructs to provide flow control schemes for
scale. Depending upon the number of neighbors and traffic classes
per neighbor support requirement, we propose three flow control
schemes based on PFC.
1. Priority-based Flow Control (PFC) using CoS: This mechanism is
limited to use 8 priorities, which must be distributed over
traffic classes and neighbors. It can be used if there are few
neighbors or traffic classes (their product not exceeding 8).
2. PFC in conjunction with MAC address: The PFC mechanism is
augmented with the Source MAC value in the PFC pause frame. The
CoS values of 802.1p field defined in [802.1q] classify the
traffic destined to a neighbor into 8 traffic classes, and the
source mac address value is used to map it to the neighbor whose
traffic class is under congestion.
Dalela Expires September 15, 2016 [Page 4]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
3. PFC in conjunction with VLAN tagging: The PFC mechanism is used
in conjunction with the 802.1q VLAN ID. The VLAN ID represents
traffic to a particular neighbor, and 8 traffic classes to each
neighbor are supported.
The traffic flow control schemes needs to cater to following traffic
flow scenarios:
1. Router to Modem traffic - When a DLEP router sends data to the
modem and the modem's RF link is experiencing congestion, the
modem MUST send a PFC PAUSE frame to the router.
2. Modem to Router traffic - When a DLEP modem is sending data to
the router and the router experiences congestion on its egress
port it MUST send a PFC PAUSE frame to the modem.
The PFC pause frame sent by the modem MUST have information about
the DLEP neighbor that is experiencing congestion in addition to the
specific traffic class to be flow controlled.
The flow control mechanisms proposed here will be working within
DLEP peers scope, it doesn't define or propose any flow control
scheme for Modem to Modem traffic over RF link.
5. Priority-based Flow Control
In this scheme, traffic class per neighbor is characterized by the
802.1p CoS values. Hence it allows max 8 neighbors with single
traffic class per neighbor. Conversely a single neighbor is
supported if there are 8 traffic classes per neighbor. For example,
if there are 2 neighbors, we can support up to 4 CoS values per
neighbor.
5.1. Operation
DLEP peers supporting this method of flow control MUST include a
DLEP 'Extensions Supported' data item, including the value TBD
representing this extension in the appropriate DLEP Session
Initialization and Session Initialization Response messages. As part
of DLEP Destination UP Response message, the router will use the
"CoS bitmap Data Item" to assign CoS values to the individual DLEP
peers. Refer section 5.2 for details.
Traffic destined to modem is mapped to a unique CoS value based on
the ingressing packets traffic class and the neighbor it is destined
to. CoS value characterizes the traffic class per neighbor.
Dalela Expires September 15, 2016 [Page 5]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
The logical queue in a router or a modem implementing this scheme is
a function of Class of Service value.
The router SHALL decide at initialization time how many neighbors
and CoS values per neighbor to support.
The modem MUST assign the CoS value, obtained from the router, to
all incoming packets from the RF link and then send it to the
router.
5.2. PFC Data Item Definitions
1. CoS bitmap
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
+----------------------------------------------------------------+
|Data Item Type | Length |
+----------------------------------------------------------------+
|CoS bitmap |
+----------------------------------------------------------------+
Figure 1 Assignment of CoS values to Neighbor
Data Item Type: TBD
Length: 4
CoS bitmap: The "Cos Values" allocated to traffic classes for a
neighbor.
5.3. Limitations
All neighbors and their traffic classes need to be allocated from
the total available 8 CoS values, which greatly reduces the number
of neighbors and the number of traffic classes per neighbor that can
be supported.
6. PFC using CoS and MAC for DLEP flow control
DLEP peers supporting this method of flow control MUST include a
DLEP 'Extensions Supported' data item, including the value TBD
representing this extension in the appropriate DLEP Session
Initialization and Session Initialization Response messages.
When the router or modem is generating the pause frame, it MUST set
the value of the source MAC address to the MAC address of the DLEP
Dalela Expires September 15, 2016 [Page 6]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
neighbor corresponding to which logical queues threshold has been
hit. On receiving the pause frame, the DLEP peer MUST use SMAC value
in addition to the traffic class to identify the queue to start/stop
traffic.
The logical queue in a router or a modem implementing this scheme is
a function of Class of Service value and the source MAC address.
6.1. PFC PAUSE frame
IEEE 802.1Qbb standards PAUSE frame is re-interpreted to support
this scheme using both Class of Service and MAC. The SMAC denotes
the MAC of the DLEP neighbor instead of its own MAC.
+-------------------------------------------------------------------
|DMAC|01:80:C2:00:00:01 |
+-------------------------------------------------------------------
|SMAC|XX:XX:XX:XX:XX:XX |
+-------------------------------------------------------------------
|EthType|0x8808 |
+-------------------------------------------------------------------
|Opcode |0x0101 |
+-------------------------------------------------------------------
|Class Enable Vector| N=0..7 0-Ignore Class N/1-Pause Class N |
+-------------------------------------------------------------------
|Time (Class 0) |
+-------------------------------------------------------------------
|Time (Class 1) |
+-------------------------------------------------------------------
|.. |
+-------------------------------------------------------------------
|Time (Class 7) |
+-------------------------------------------------------------------
|PAD |
+-------------------------------------------------------------------
|CRC |
+-------------------------------------------------------------------
Figure 2 PFC PAUSE frame
The PFC PAUSE frame has the following fields:
1. Destination MAC: 6 octets, is reserved: 01:80:C2:00:00:01.
2. Source MAC: 6 octets, The SMAC is set to the MAC of the DLEP
neighbor.
Dalela Expires September 15, 2016 [Page 7]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
3. EtherType: 2 octets, the ethertype is set to 0x8808 to indicate
flow control.
4. OpCode: 2 octets, The opcode field is set to 0x0101 to indicate
PFC.
5. Class-enable vector: 2 octets, The 16 bits of the 2 octets are
set to either to 0 or 1; generate pause(1) or ignore(0) for each
of the 8 CoS values.
6. Time/Class n: 2 octets per CoS totaling 16 octets for 8 different
CoS values indicating the time to pause the particular CoS value.
Each field has a range of 0-0xFFFF. A value of zero has the
meaning of unpausing the link.
7. PAD: 28 octets of padding.
8. CRC - The Cyclic redundancy check.
7. PFC using the VLAN ID for DLEP flow control
In this scheme, traffic class per neighbor is characterized by the
CoS values and Vlan is used to identify the neighbor. Hence it
allows up to 4K neighbors with 8 traffic classes per neighbor; that
is, a modem can be paired with 4K other modems over RF. To support
such a scheme, Vlan-id needs to be carried in the PFC PAUSE frame
generated by modem to distinguish PAUSE frames corresponding to
different neighbors. We propose to add IEEE 802.1Q tag to the PFC
PAUSE frame generated by a DLEP node to carry the Vlan-ID indicating
the neighbor for which the PAUSE frame has been generated.
7.1. Operation
DLEP peers supporting this method of flow control MUST support and
conform to [VLANS-DLEP] extension.
DLEP peers supporting this method of flow control MUST include a
DLEP 'Extensions Supported' data item, including the value TBD
representing this extension in the appropriate DLEP Session
Initialization and Session Initialization Response messages. This
extension MUST be negotiated only in combination with one of the
supported encapsulations listed in [VLANS-DLEP] extension.
When the router or modem is generating the PFC PAUSE frame, it MUST
tag the pause frame 802.1Q tag with VLAN-ID indicating the neighbor
experiencing congestion. On receiving PAUSE frame, the DLEP peer
Dalela Expires September 15, 2016 [Page 8]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
MUST use VLAN-ID in addition to traffic class to identify the queue
to start/stop traffic.
The logical queue in a router or a modem implementing this scheme is
a function of the Class of Service value and the VLAN-ID assigned to
the neighbor of the neighbor.
7.2. Tagged PFC PAUSE frame
We propose to use the PFC PAUSE frame defined in IEEE 802.1Qbb with
an IEEE 802.1Q tag.
+-------------------------------------------------------------------
|DMAC |01:80:C2:00:00:01 |
+-------------------------------------------------------------------
+SMAC |XX:XX:XX:XX:XX:XX |
+-------------------------------------------------------------------
|TPID |0x8100 |
+-------------------------------------------------------------------
|PCP/DEI |12-bit VLAN ID |
+-------------------------------------------------------------------
|EthType|0x8808 |
+-------------------------------------------------------------------
|Opcode |0x0101 |
+-------------------------------------------------------------------
|Class Enable Vector| N=0..7 0-Ignore Class N/1-Pause Class N |
+-------------------------------------------------------------------
|Time (Class 0) |
+-------------------------------------------------------------------
|Time (Class 1) |
+-------------------------------------------------------------------
|.. |
+-------------------------------------------------------------------
|Time (Class 7) |
+-------------------------------------------------------------------
|PAD |
+-------------------------------------------------------------------
|CRC |
+-------------------------------------------------------------------
Figure 3 PFC PAUSE frame for Vlan and CoS PFC
The tagged PFC PAUSE frame has the following fields:
1. Destination MAC: 6 octets, is reserved: 01:80:C2:00:00:01.
2. Source MAC: 6 octets, The MAC address of the sender of the PFC
PAUSE frame.
Dalela Expires September 15, 2016 [Page 9]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
3. Tag Protocol Identifier: 2 octets, The TPID is set to 0x8100 to
indicate VLAN tagging.
4. PCP/DEI/VLAN ID: 2 octets, The 12-bit VID field is used to
indicate the number of PFC "virtual links".
5. EtherType: 2 octets, is set to 0x8808 to indicate flow control.
6. OpCode: 2 octets, is set to 0x0101 to indicate PFC.
7. Time/Class n: 2 octets per CoS totaling 16 octets for 8 different
CoS values indicating the time to pause the particular CoS value.
Each field has a range of 0-0xFFFF. A value of zero has the
meaning of unpausing the link.
8. Pad: 28-octets of padding.
9. CRC - The Cyclic redundancy check.
8. Security Considerations
Security considerations similar to [CREDIT] extension are applicable
here. This extension doesn't bring in any new security
considerations.
9. IANA Considerations
This section specifies requests to IANA.
9.1. Registrations
This specification defines new data items for DLEP. Assignments from
the DLEP data item registry are requested for:
1. CoS bitmap
10. References
10.1. Normative References
[DLEP] Ratliff, S., Berry, B., Jury, S., Satterwhite, D. ,Taylor,
R., "Dynamic Link Exchange Protocol (DLEP)",
https://tools.ietf.org/html/draft-ietf-manet-dlep-19
[CREDIT] Ratliff, S.,"Credit Windowing extension for DLEP",
https://tools.ietf.org/html/draft-ietf-manet-credit-window-02
Dalela Expires September 15, 2016 [Page 10]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
[VLANS-DLEP] Dalela, A., Parashar, A., Ananth S., L., "VLANs and
DLEP", https://tools.ietf.org/html/draft-dalela-vlans-and-dlep-01
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119
[802.1Q] IEEE 802.1Q, "Virtual LANs",
http://www.ieee802.org/1/pages/802.1Q.html
[802.1Qbb] IEEE 802.1Qbb or PFC, "Priority-based Flow Control",
http://www.ieee802.org/1/pages/802.1bb.html
11. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior
written permission.
Dalela Expires September 15, 2016 [Page 11]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
Dalela Expires September 15, 2016 [Page 12]
Internet-Draft Flow Control Mechanisms for DLEP March 2016
Authors' Addresses
Ashish Dalela
Cisco Systems,
Cessna Business Park,
Bangalore 560103
India
Email: adalela@cisco.com
Arun Parashar
Cisco Systems,
Cessna Business Park,
Bangalore 560103
India
Email: arparash@cisco.com
S L Ananth
Cisco Systems,
Cessna Business Park,
Bangalore 560103
India
Email: alaxmina@cisco.com
Dalela Expires September 15, 2016 [Page 13]
