draft-ietf-idr-flow-spec-02.txt   draft-ietf-idr-flow-spec-03.txt 
IDR Working Group P. Marques IDR Working Group P. Marques
Internet-Draft N. Sheth Internet-Draft N. Sheth
Expires: March 7, 2009 R. Raszuk Expires: May 24, 2009 R. Raszuk
B. Greene B. Greene
Juniper Networks Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT/Verio
D. McPherson D. McPherson
Arbor Networks Arbor Networks
September 3, 2008 November 20, 2008
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-02 draft-ietf-idr-flow-spec-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 7, 2009. This Internet-Draft will expire on May 24, 2009.
Abstract Abstract
This document defines a new BGP NLRI encoding format that can be used This document defines a new BGP NLRI encoding format that can be used
to distribute traffic flow specifications. This allows the routing to distribute traffic flow specifications. This allows the routing
system to propagate information regarding more-specific components of system to propagate information regarding more-specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
Additionally it defines two applications of that encoding format. Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic One that can be used to automate inter-domain coordination of traffic
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 2. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6
3. Dissemination of Information . . . . . . . . . . . . . . . . . 7 3. Dissemination of Information . . . . . . . . . . . . . . . . . 7
4. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13 4. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Order of traffic filtering rules . . . . . . . . . . . . . 14 4.1. Order of traffic filtering rules . . . . . . . . . . . . . 14
5. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15 5. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15
6. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 6. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17
7. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 19 7. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 19
8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security considerations . . . . . . . . . . . . . . . . . . . 21 9. Security considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Normative References . . . . . . . . . . . . . . . . . . . . . 24 12. Normative References . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to aggregate IP prefixes as well as to classify, shape, according to aggregate IP prefixes as well as to classify, shape,
limit filter or redirect packets based on administratively defined limit filter or redirect packets based on administratively defined
policies. policies.
While forwarding information is, typically, dynamically signaled While forwarding information is, typically, dynamically signaled
across the network via routing protocols, there is no agreed upon across the network via routing protocols, there is no agreed upon
skipping to change at page 17, line 38 skipping to change at page 17, line 38
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| type | extended community | encoding | | type | extended community | encoding |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float | | 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| | | | | | | |
| 0x8007 | traffic-action | bitmask | | 0x8007 | traffic-action | bitmask |
| | | | | | | |
| 0x8008 | redirect | 6-byte Route Target | | 0x8008 | redirect | 6-byte Route Target |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
Traffic-rate The traffic-rate extended community uses the same Traffic-rate The traffic-rate extended community is a non-transitive
encoding as the "Link Bandwidth" [RFC4360] extended community. extended community across the Autonomous system boundary and uses
The rate is is expressed as 4 octets in IEEE floating point following extended community encoding:
format, units being bytes per second. A traffic-rate of 0 should
result on all traffic for the particular flow to be discarded. The first two octets carry the 2 octet id which can be assigned
from a 2 byte AS number
The remaining 4 octets carry the rate information in IEEE
floating point format, units being bytes per second. A
traffic-rate of 0 should result on all traffic for the
particular flow to be discarded.
Traffic-action The traffic-action extended community consists of 6 Traffic-action The traffic-action extended community consists of 6
bytes of which only the 2 least significant bits of the 6th byte bytes of which only the 2 least significant bits of the 6th byte
(from left to right) are currently defined. (from left to right) are currently defined.
* Terminal action (bit 0). When this bit is set the traffic * Terminal action (bit 0). When this bit is set the traffic
filtering engine will apply any subsequent filtering rules (as filtering engine will apply any subsequent filtering rules (as
defined by the ordering procedure). If not set the evaluation defined by the ordering procedure). If not set the evaluation
of the traffic filter stops when this rule is applied. of the traffic filter stops when this rule is applied.
skipping to change at page 22, line 12 skipping to change at page 22, line 12
Where it not the case, this would open the door to further denial of Where it not the case, this would open the door to further denial of
service attacks. service attacks.
10. IANA Considerations 10. IANA Considerations
A flow specification consists of a sequence of flow components, which A flow specification consists of a sequence of flow components, which
are identified by a an 8-bit component type. Types must be assigned are identified by a an 8-bit component type. Types must be assigned
and interpreted uniquely. The current specification defines types 1 and interpreted uniquely. The current specification defines types 1
though 12, with the value 0 being reserved. though 12, with the value 0 being reserved.
For the purpose of this work IANA has allocated values for two SAFIs:
SAFI 133 for IPv4 and SAFI 134 for VPNv4 dissemination of flow
specification rules.
The following traffic filtering flow specification rules are to be
allocated by IANA from BGP Extended Communities Type - Experimental
Use registry. Authors recommend the following type values:
0x8006 - Flow spec traffic-rate
0x8007 - Flow spec traffic-action
0x8008 - Flow spec redirect
Authors would like to ask IANA to create and maintain a new registry
entitled: "Flow Spec Component Type". Authors recommend to allocate
the following component types:
Type 1 - Destination Prefix
Type 2 - Source Prefix
Type 3 - IP Protocol
Type 4 - Port
Type 5 - Destination port
Type 6 - Source port
Type 7 - ICMP type
Type 8 - ICMP code
Type 9 - TCP flags
Type 10 - Packet length
Type 11 - DSCP
Type 12 - Fragment
In order to manage the limited number space and accommodate several In order to manage the limited number space and accommodate several
usages the following policies defined by RFC 5226 [RFC5226] are used: usages the following policies defined by RFC 5226 [RFC5226] are used:
+--------------+-------------------------------+ +--------------+-------------------------------+
| Range | Policy | | Range | Policy |
+--------------+-------------------------------+ +--------------+-------------------------------+
| 0 | Invalid value | | 0 | Invalid value |
| | | | | |
| [1 .. 12] | Defined by this specification | | [1 .. 12] | Defined by this specification |
| | | | | |
skipping to change at page 23, line 5 skipping to change at page 23, line 31
The specification of a particular "flow component type" must clearly The specification of a particular "flow component type" must clearly
identify what is the criteria used to match packets forwarded by the identify what is the criteria used to match packets forwarded by the
router. This criteria should be meaningful across router hops and router. This criteria should be meaningful across router hops and
not depend on values that change hop-by-hop such as ttl or layer-2 not depend on values that change hop-by-hop such as ttl or layer-2
encapsulation. encapsulation.
The "Traffic-action" extended community defined in this document has The "Traffic-action" extended community defined in this document has
6 unused bits which can be used to convey additional meaning. These 6 unused bits which can be used to convey additional meaning. These
values should be assigned via IETF Consensus rules only. values should be assigned via IETF Consensus rules only.
Future assignment are to be made using either the Standards Action
process defined in [RFC2434], the Early IANA Allocation process
defined in [RFC4020], or the "First Come First Served" policy defined
in [RFC2434].
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Yakov Rekhter, Dennis Ferguson and The authors would like to thank Yakov Rekhter, Dennis Ferguson and
Chris Morrow for their comments. Chris Morrow for their comments.
Chaitanya Kodeboyina helped design the flow validation procedure. Chaitanya Kodeboyina helped design the flow validation procedure.
Steven Lin and Jim Washburn ironed out all the details necessary to Steven Lin and Jim Washburn ironed out all the details necessary to
produce a working implementation. produce a working implementation.
 End of changes. 8 change blocks. 
13 lines changed or deleted 65 lines changed or added

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