[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group F. Baker
Internet-Draft Cisco Systems
Intended status: Informational July 1, 2011
Expires: January 2, 2012
Routing a Traffic Class
draft-baker-fun-routing-class-00
Abstract
This note addresses the concept of routing a traffic class. This has
many possible implementations, IGP and BGP, and link state as well as
distance vector. The fundamental impetus is the question raised in
RFC 3704 and shim6 of exit routing, the question raised by Mike
O'Dell of source/destination routing, and the "fish" problem, raised
in many networks, in which distinct traffic classes that could
conceivably use the same route predictably use different routes.
Instead of handling these as "destination routing with a twist", the
paper looks at the matter systemically.
Requirements
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 [RFC2119].
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 2, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Baker Expires January 2, 2012 [Page 1]
Internet-Draft Routing a Traffic Class July 2011
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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Structure of the paper . . . . . . . . . . . . . . . . . . 3
2. The fundamental concept of routing a class . . . . . . . . . . 3
2.1. Define: "traffic class" . . . . . . . . . . . . . . . . . 4
2.2. Define: "metric" . . . . . . . . . . . . . . . . . . . . . 5
2.3. Define: "route announcement" . . . . . . . . . . . . . . . 5
2.4. Route Precedence . . . . . . . . . . . . . . . . . . . . . 7
3. Sketch of a distance vector implementation . . . . . . . . . . 8
4. Sketch of a link state implementation . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Baker Expires January 2, 2012 [Page 2]
Internet-Draft Routing a Traffic Class July 2011
1. Introduction
This note addresses the concept of routing a traffic class. This has
many possible implementations, IGP and BGP, and link state as well as
distance vector. The fundamental impetus is the question raised in
[RFC3704] and shim6 of exit routing, the question raised by Mike
O'Dell of source/destination routing, and the "fish" problem, raised
in many networks, in which distinct traffic classes that could
conceivably use the same route predictably use different routes.
Instead of handling these as "destination routing with a twist", the
paper looks at the matter systemically.
1.1. Scope
The question of implementation of IPv4 or IPv6 routes is moot; the
algorithms discussed here can be used for either. Examples, however,
will be drawn from IPv6 [RFC2460] and will presume its addressing
architecture [RFC4291].
1.2. Structure of the paper
The paper looks first at the fundamental concept in Section 2. It
then goes on to imagine an IS-IS-like [RFC5308] [RFC6119]
implementation. Unfortunately, this really can't be implemented in
IS-IS by adding a TLV, which is our usual approach, due to the
changed concept of a metric. However, given the changed concepts of
a metric and a TLV, it shows how the same exchange and calculation
algorithms can be used to build such a routing protocol. It also
looks at a RIP-like [RFC2080] algorithm that includes a sequence
number (derived from AODV [RFC3561]) to simplify count-to-infinity-
related problems. It stops short of a BGP implementation, although
one modeled on the distance vector model would make sense.
2. The fundamental concept of routing a class
This section introduces the fundamental concepts involved in routing
a traffic class. These include the definitions of
o a "traffic class", which is a set-theoretic definition - all
traffic matching a constraint,
o a "metric", which is an administrative number applied to a class
of traffic crossing an interface, and
o a "route announcement", which is the accumulation of information
regarding the routing of a traffic class as modified by various
metrics en route.
Baker Expires January 2, 2012 [Page 3]
Internet-Draft Routing a Traffic Class July 2011
In addition, it describes the fundamental algorithm applied in
modifying a route announced by a predecessor node using a metric for
announcement on the interface implied.
2.1. Define: "traffic class"
A "class" of traffic, in any routing protocol, is the selector that
is used to identify a traffic stream for the purpose of routing. For
traditional internet routing protocols like RIP, OSPF, IS-IS, EIGRP,
or BGP, a "traffic class" is "the traffic destined to a stated
prefix". In the context of this design, a traffic class is the
traffic that goes
o to a destination prefix, which may be a default route (::/0), a
host route (any /128 prefix), or anything in between,
o from a source prefix, which may be a default route (::/0), a host
route (any /128 prefix), or anything in between, and
o using one of a set of DSCP [RFC2474] values.
The set of DSCP values includes and "any DSCP". "Any DSCP" has the
obvious meaning: we are not really looking at the DSCP in traffic
classification.
A protocol could also identify a route as a "null route"; this is
like any other route, but specifically directs that traffic matching
the traffic class is to be dropped.
A traffic class is represented in this document as
{destination, source, {list of DSCPs}|any|none}
Examples of common traffic classes include:
Standard Default Route: {::/0, ::/0, any}
Default Route using a source prefix {::/0, source, any}
Default route used only for a QoS Traffic Class: {::/0, ::/0, {list
of DSCPs}}
Examples of QoS traffic classes are found in the Configuration
Guidelines for DiffServ Service Classes [RFC4594] and related
documents [RFC5127] and [RFC5865].
Baker Expires January 2, 2012 [Page 4]
Internet-Draft Routing a Traffic Class July 2011
2.2. Define: "metric"
A "metric" is an attribute of an interface, and associates a traffic
class with a administrative value used in comparison of routes. In
this document, it is represented as
{{destination, source, {DSCP}|any|none}, administrative value}
and should be understood as "the metric for traffic from source to
destination using DSCP".
For example, if an interface is available to all VoIP traffic, one of
the metrics on an interface might be
{{::/0, ::/0, {EF}}, administrative value}
2.3. Define: "route announcement"
A route announcement is identical to a metric in structure, but is
semantically different. Where a metric is an attribute of an
interface, a route is an entry in the route table calculated by the
routing protocol, and is used in making forwarding decisions.
The calculation of a route follows the following logic:
1. Inputs to the route calculation are a route announcement (which
may be derived from an interface metric in the case of local
routes, or received from a neighboring route for remote routes),
and a metric associated with an interface.
2. The source, destination, and set of DSCPs of the route
announcement and the metric are intersected to generate the
traffic class for the resulting route.
3. The resulting route's administrative value is the sum of the
original route's administrative value and the interface's
administrative value.
For example, in Figure 1, if the prefix allocated by ISP-1 to a
network is 2001:db8:1::/48 and the prefix allocated by ISP-2 to the
network is 2001:db8:2::/48, the exit routers for the network might
advertise into the network the default routes
o {{2000::/3, 2001:db8:1::/48, any}, 1} ("unicast traffic using
source addresses in 2001:db8:1::/48 for any application"), and
o {{::/0, 2001:db8:2::/48, any}, 2} ("all traffic using source
addresses in 2001:db8:2::/48 for any application").
Baker Expires January 2, 2012 [Page 5]
Internet-Draft Routing a Traffic Class July 2011
\ / \ /
`. ISP-1 ,' `. ISP-2 ,'
'--. _.-' '--. _.-'
`---+--'' `--+---''
| |
+--+---+ +--+---+
| Exit | | Exit |
|Router| |Router|
+---+--+ +---+--+
------+------------+- -+-------------+-----
+-+----+-+
|Interior|
| Router |
+---+----+
-------+--------
Figure 1: Simple multihomed network
One edge case is the case in which a route intersected with the
available metrics yields the null set. In such a case, the resulting
route cannot be used as no traffic matches it.
If an interior distance vector router in the network receives
{{2000::/3, 2001:db8:1::/48, any}, 1} and
{{::/0, 2001:db8:2::/48, any}, 2}
from its upstream router, and on a given interface has a metric
{{::/0, ::/0, {EF}}, 5} ("any VoIP traffic"),
it would validly infer the routes
{{2000::/3, 2001:db8:1::/48, {EF}}, 6} ("unicast VoIP traffic
using source addresses in 2001:db8:1::/48") and
{{::/0, 2001:db8:2::/48, {EF}}, 7} ("all VoIP traffic using source
addresses in 2001:db8:2::/48").
It would install the routes it received into its own route table, and
advertise the calculated routes to neighboring routers.
Note that there is no question of a unicast RPF or other forms of
Ingress Filtering [RFC2827] required in such a network. If a host
spoofs a source address in another routing domain and sends a
datagram upstream, there is no route in the network "from" that
routing domain, and the router has no idea what to do with it. In
Baker Expires January 2, 2012 [Page 6]
Internet-Draft Routing a Traffic Class July 2011
such cases the router would silently drop the traffic (it might be
nice to respond with an ICMP, but to whom?); it should of course
maintain appropriate counters and/or logs. Similarly, since traffic
is routed according to both its source and destination addresses,
traffic using a source address in 2001:db8:2::/48 would have no
chance of existing to ISP-1. It is still possible for traffic from
outside to come in, however, as such routes would have a source
prefix of ::/0 or 2000::/3.
2.4. Route Precedence
Precedence in selection of routes is based on intersection, and
follows the rule "most specific first". This is a generalization of
the "longest match first" rule used in destination routing. That may
require, in generating the Forwarding Information Base (FIB) from the
Routing Information Base (RIB), that we calculate the least
intersection of two route announcements.
In calculating routes, either one route's traffic class is a subset
of another's, or they mutually incompatible. If one is a subset of
the other, we consider the superset to be "less specific" and the
subset to be "more specific"; the most specific matching traffic
class rules. If the most specific option is in fact multiple traffic
classes none of which are subsets of the others, we calculate the
intersections of those routes for the purpose of comparison, and
apply the rule to the resulting route announcements.
For example, consider the two routes
{{2000::/3, ::/0, any}, 1} and
{{::/0, 2000::/3, any}, 5}.
They are not comparable because neither is a subset of the other. We
therefore calculate the intersection, which is a choice between
{{2000::/3, 2000::/3, any}, 1} and
{{2000::/3, 2000::/3, any}, 5}.
Given that choice, the metric clearly selects {{2000::/3, 2000::/3,
any}, 1}. So we install in the RIB the three routes
{{2000::/3, 2000::/3, any}, 1},
{{2000::/3, ::/0, any}, 1}, and
Baker Expires January 2, 2012 [Page 7]
Internet-Draft Routing a Traffic Class July 2011
{{::/0, 2000::/3, any}, 5}.
The first is used by unicast traffic, as it is the most specific that
matches traffic from and to addresses in 2000::/3. The second is
used, for example, with traffic that is from addresses whose most
significant three bits are not 001 and to an address in 2000::/3.
The third is used for traffic that is to addresses whose most
significant three bits are not 001 but are from addresses in
2000::/3.
3. Sketch of a distance vector implementation
A distance vector implementation would operate much as described in
Section 2. In addition, however, we might take advantage of an
algorithm used in AODV [RFC3561]) to simplify count-to-infinity-
related problems.
To this end, we use the mechanisms and algorithms of [RFC2080] with
certain modifications.
A Route Table Entry (RTE), in this model, might be structured as in
Figure 2.
Baker Expires January 2, 2012 [Page 8]
Internet-Draft Routing a Traffic Class July 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| route tag (2) |A|N| flags | metric (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Announcement sequence number (4) |
+---------------------------------------------------------------+
| |
~ IPv6 originator address (16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dest prefix len|source prf len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 destination prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 source prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Traffic Class DSCP (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Route Table Entry
The fields are:
Route Tag: The Route Tag is as defined in [RFC2080].
A: If 1, any DSCP applies, and the IPv6 Traffic Class DSCP mask is
absent. If 0, the IPv6 Traffic Class DSCP is present.
N: if 1, a null route; traffic in this traffic class and not in more
explicit match SHOULD be dropped.
flags: unspecified in this version of the specification. Set to 0
on transmission and ignored on receipt. Future versions may
specify additional flags.
Metric: The Metric is as defined in [RFC2080].
Announcement sequence number: 0..FFFFFFFF, follows the rules for a
sequence number specified in [RFC3561].
Baker Expires January 2, 2012 [Page 9]
Internet-Draft Routing a Traffic Class July 2011
IPv6 originator address: One of the global addresses of the router
originating this RTE, presumably the one used on the relevant
interface, which is in control of the sequence number. See
[RFC3561] for considerations and algorithms.
Destination Prefix Length: 0..128
Source Prefix Length: 0..128
IPv6 destination prefix: The significant bits of the prefix in
question. Occupies ceiling(destination prefix length/8) bytes.
IPv6 source prefix: The significant bits of the prefix in question.
Occupies ceiling(source prefix length/8) bytes.
IPv6 Traffic Class DSCP: if A=0, not present; if A=0, the most
significant bit is numbered 0, and indicates that the traffic
class includes traffic with a DSCP of 000000; if A=1, not present.
Distribution and calculation of routes follows [RFC2080], including
split horizon (an announcement received from a router on the
interface should not be reannounced to the same router). and poison
reverse (which should be used on triggered updates but not regular
announcements).
Elimination of stale routing information of routes follows the
algorithm with the sequence number specified in [RFC3561].
Intersection of route announcements with interface metric data is as
described in Section 2.
4. Sketch of a link state implementation
A link state (SPF) implementation would also operate much as
described in Section 2, although the algorithm operates in memory as
opposed to being distributed.
To this end, we use the mechanisms and algorithms of [RFC5308] with
certain modifications.
IS-IS structures its network as a lattice of routers that lead one to
sets of hosts identified by "TLVs". A TLV, in this model, might be
structured as in Figure 3.
Baker Expires January 2, 2012 [Page 10]
Internet-Draft Routing a Traffic Class July 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ??? | Length | Metric .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Metric |U|X|S| Reserve | TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV Len(*) | Sub-TLVs(*) ...
* - if present
TLV or sub-TLV format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dest prefix len|source prf len |A|N|flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 destination prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 source prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Traffic Class DSCP (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Link State Advertisement TLV
The fields are:
U: up/down bit
X: external original bit
S: subtlv present bit
A: If 1, any DSCP applies, and the IPv6 Traffic Class DSCP mask is
absent. If 0, the IPv6 Traffic Class DSCP is present.
N: if 1, a null route; traffic in this traffic class and not in more
explicit match SHOULD be dropped.
Baker Expires January 2, 2012 [Page 11]
Internet-Draft Routing a Traffic Class July 2011
flags: unspecified in this version of the specification. Set to 0
on transmission and ignored on receipt. Future versions may
specify additional flags.
Destination Prefix Length: 0..128
Source Prefix Length: 0..128
IPv6 destination prefix: The significant bits of the prefix in
question. Occupies ceiling(destination prefix length/8) bytes.
IPv6 source prefix: The significant bits of the prefix in question.
Occupies ceiling(source prefix length/8) bytes.
IPv6 Traffic Class DSCP: if A=0, not present; if A=0, the most
significant bit is numbered 0, and indicates that the traffic
class includes traffic with a DSCP of 000000; if A=1, not present.
Distribution and calculation of routes follows [RFC5308].
Intersection of route announcements with interface metric data is as
described in Section 2.
5. IANA Considerations
At this point, this memo asks the IANA for no new parameters and
gives the IANA no instructions. As development progresses, that
might change.
6. Security Considerations
Security issues in routing protocols such as these are the same as in
other distance vector and link state routing protocols, and need to
be mitigated in the same ways. Since this paper looks primarily at
the algorithms for route calculation, those issues are largely
ignored. If a protocol such as described in Section 3 or Section 4
is implemented, however, care must be taken to ensure the integrity
of communications between routers and their mutual authentication.
7. Acknowledgements
Dana Blair reviewed the initial version of the draft.
Baker Expires January 2, 2012 [Page 12]
Internet-Draft Routing a Traffic Class July 2011
8. Change Log
Initial Version: Sat Mar 26 12:25:46 CET 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008.
Baker Expires January 2, 2012 [Page 13]
Internet-Draft Routing a Traffic Class July 2011
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires January 2, 2012 [Page 14]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/