F. Reichmeyer
Internet Draft PFN
(Editor)
Category: Informational W. Weiss
Ellacoya
November 2001
Tunnel Endpoint Configuration and Route Binding
draft-franr-tunman-endpoint-config-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This draft specifies the configuration information that will be used
to define, establish,activate, and maintain tunnel facilities. As IP-
based services, such as VPNs, grow in popularity, tunnel
configuration and management becomes ever more important since these
services and mechanisms proposed for their deployment are based on
tunnels and tunneling protocols. It is important, then, that an
interface exist such that tunnel management semantics can be provided
in a vendor-independent manner, and for a number of services,
including L2 and L3 services. Tunnels are fundamentally encapsulation
strategies applied to packets as part of the forwarding process
within a router. Similar to the prior efforts in the DiffServ
working group, that allow for the configuration of other router
datapath elements including classifiers, meters and markers this work
seeks to define additional datapath elements that allow for the
representation and configuration of tunnel encapsulation and
deencapsulation elements.
Reichmeyer, et.al. Expires - May 2002 1
draft-franr-tunman-endpoint-config-00.txt November 2001
2. Conventions used in this document
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 [2].
3. Introduction
In today's Internet, tunnels are established and activated to provide
a facility for conveying specific traffic from one point to another,
to support a number of IP service offerings, for example IP VPNs
(Virtual Private Networks). The increasing growth of such advanced
services systematically implies the configuration of a large set of
information for the actual provisioning, establishment, and
maintenance of such tunnels.
Configuration information includes: endpoint identification (which
routers are the endpoints of the tunnel); forwarding information
(what traffic should be carried in the tunnel, etc.); security
considerations (identification and authentication of the users who
are granted access to the tunnel, encryption of the data, etc.); and
Quality of Service (QoS) considerations (e.g. the DSCP marking
associated to the packets to be carried over the tunnel). To
establish the tunnels, information is required about (signaling
and/or routing) protocols, and necessary parameters, that are used to
create the tunnel, exchange encapsulation unformation, etc.
Maintenance information includes that which is associated with the
measurement of tunnel traffic, tunnel status monitoring, etc.
Due to the many different tunnel mechanisms and protocols to
consider, for example MPLS, IPsec, L2TP, etc., and to the increased
complexity of deploying the corresponding value-added IP service
offerings, it is important, then, that an interface exists such that
tunnel management configuration information can be dynamically
provided in a vendor-independent manner, and for a number of
services, whatever the underlying technology.
We are concerned with a general framework for the configuration and
management of tunnels and their use to implement IP services, such as
IP-based VPN services, according to the requirements for dynamic
tunnel configuration, as discussed in [3]. These different tunnel
types are often used to provide different services where the type of
tunnel used is determined by the type of service desired.
In order to get a grip on the complexities associated with tunnel
configuration management, we break discussion into the following four
categories:
- Endpoint Discovery and Setup
- Route Binding
- Data Path Provisioning and Encapsulation
Reichmeyer, et.al. Expires - May 2002 2
draft-franr-tunman-endpoint-config-00.txt November 2001
- Statistics Collection/Feedback
The first two topics are discussed here while the others are
discussed in separate drafts, [4], [5].
This draft addresses the first two of these; endpoint configuration
and route binding. We will define the means for provisioning
endpoints for constructing tunnels either dynamically, for example
based on EGP leaking or some other methods, or statically, for
example for simple IGPs.
Regardless of the type of tunnel mechanism(s) used or the service
being deployed over the tunnel, the tunnel endpoints need to be
identified. Tunnels may involve only two endpoints (point-to-point)
or more than two (point-to-multipoint). Multiple endpoints of
multiple tunnels may be logically grouped together, depending on the
application of the tunnels. For example, all endpoints of all tunnels
in a VPN comprise the participating devices of the VPN and would
likely be identified as such. In such instances, tunnel endpoints,
and tunnels themselves, may be added and removed dynamically from the
grouping without affecting the rest of the configured group.
Tunnels may be associated to the set of users that are entitled to
access the tunnel, and tunnel endpoints may be identified and grouped
according to the users serviced by the endpoints. The provisioning
and activation of the tunnels may be conditioned by the users
themselves, for example L2TP tunnels. Also, some examples of
applications for tunnels do not require that all endpoints be
systematically associated directly to users, for example IPv6
migration scenarios.
Once the tunnel endpoints are identified, using whatever means
defined, the connection(s) must be established to create the tunnels
themselves, used to carry data between the enpoints. There are many
ways in which these operations can occur, depending on the type of
tunnels to be used and/or on the type of services to be offered over
the tunnels. When tunnel endpoints are identified, they must be
configured with information used to specifying the tunnel signaling
protocol to be used in establishing the tunnel with the other tunnel
endpoint(s).
After a tunnel is created, the tunnel endpoint(s) must be provisioned
to appropriately ensure the correct routing/forwarding information is
bound to the correct tunnel(s) on the router. We will be discussing
static routing within the context of policy datapaths, as well as
dynamic routing and the bindings of dynamic routing engines to sets
of tunnels.
One of the elements of some tunneling protocols is the ability to
specify QoS either explicitly within the tunnel or through routing
strategies that choose specific tunnels based on the QoS criteria of
a specific type of traffic. Because of this, it seems natural to
build on QoS configuration semantics already defined in other WGs.
Reichmeyer, et.al. Expires - May 2002 3
draft-franr-tunman-endpoint-config-00.txt November 2001
Specifically, the DiffServ WG has defined a model, a MIB and PIB that
allow for a flexible representation of the various elements involved
in forwarding packets through routers. Each element is specified in a
way that allows for the relationship between elements to be expressed
as well as the specific configuration semantics of each element. For
instance, a classifier describes the means for identifying particular
packets based on the various fields in the packet. The classifier can
be configured to match on any combination of field values. In
addition, a classifier can also be configured to indicate what
actions are to be performed on all packets matching the specific
criteria.
Additional forwarding elements defined in DiffServ configuration
documents include a meter (providing a means for testing a traffic
stream against a profile), a marker (allowing specific modifications
to existing fields of a packet), a dropper (supporting absolute,
random, and tail drop capabilities), a queue (providing isolation of
various types of traffic), and a scheduler (giving configuration
control over the allocation of link resources to various queues). As
all of these functions are also relevant to the specification of
tunneling behaviors, this draft proposes extending the DiffServ
functional model to also incorporate the ability to configure the
termination of tunnels.
3.1 Relation to Other WGs
Tunnels and the need for tunnel management are, clearly, addressed in
several other WGs. In some cases, tunnels are a means of implementing
certain network application, such as PPVPN [6] and TEWG [7], while in
other cases specific tunnel protocols are addressed, such as IPSec.
The aim of the work in this draft, and accompanying drafts [3], [4],
and [3], is not to duplicate the work in any related WGs but to
provide a general framework for the configuration and management of
tunnels such that tunnels may be effectively utilized in the
applications focused on in the other WGs. Where possible and
appropriate, mechanisms produced by other WGs will be incorporated
into this general framework. Also, any issues that may be specific to
other groups should be qualified as to how they relate and/or why
they are not sufficiently addressed to date.
Specifically, this tunnel management work differs from that of other
WGs in the following ways. First, as mentioned, this scope is more
general and, although applicable to other areas, does not
specifically focus on applications such as VPNs or Traffic
Engineering. Second, this work is expected to bind directly to the
DiffServ model [8] and the packet processing concepts defined there,
rather than building new ones specific to applications such as VPNs.
Third, this work should consider a wider range of tunneling
technologies where other groups may, necessarily, limit the scope of
tunnels that they consider. The first and third items clearly imply a
broader scope of work to be addressed here, while the second narrows
Reichmeyer, et.al. Expires - May 2002 4
draft-franr-tunman-endpoint-config-00.txt November 2001
the scope in that there are no plans to reinvent semantics defining
packet processing for the likes of QoS, security, etc.
4. Tunnel Endpoint Identification and Configuration
Identifying routers and configuring them as tunnel endpoints can be
done by a number of techniques. The aim here is at specifying and
standardizing a configuration scheme to facilitate the engineering
tasks related to the identification and configuration of routers as
tunnel endpoints, for the purpose of deploying of IP service
offerings that make use of a tunnel facility. In general, we can
classify tunnel endpoint identification as `explicit' and `implicit'.
Tunnels are provisioned for the purpose of deploying IP services,
such as VPNs, and a particular service may require multiple tunnels
to be created at a device. In the context of tunnel configuration and
provisioning, all endpoints that participate in a particular IP
service are identified with a Tunnel Service Identifier (better
name?). For example, if tunnels are to be created for a VPN
implementation, all devices that are enpoints for the VPN tunnels are
configured with the VPN identifier and tunnels are established
between all devices with the same identifier, either explicitly or
implicitly. The individual tunnels created for the service are also
specified with their own Tunnel Identifer.
In the explicit case, all devices are identified a priori as
endpoints for specific tunnels and are configured explicitly with a
Tunnel Service Id, Tunnel Id, and the necessary information to
establish the tunnel(s) between those endpoints. An example of this
is two endpoints of an IPsec connection where each endpoint is
configured with the address of the other, along with the IPsec
information required to complete the connection. Upon configuration,
the endpoints take the appropriate actions to establish the tunnel
between them, using the information provided. Since all endpoints and
tunnel mechanism information are explicitly known, no other
intermediate steps are needed to invoke the specified tunneling
protocol(s).
In the implicit case, devices are identified as tunnel endpoints and
are configured the necessary information to (dynamically) participate
in tunnel endpoint discovery mechanisms. For example, mechanisms such
as DNS, BGP/IGP routing policy, LDAP (Directory Services), and VR
address resolution via multicast can be used to dynamically identify
and configure tunnel endpoints. Routers are configured with a Tunnel
Service Id, specifying a service for which the router is to act as a
tunnel endpoint, as well as information specifying the discovery
mechanism that should be used to identify the other endpoint(s). The
specified discovery mechanism is then invoked and the other routers
configured with the same Tunnel Service Id, i.e. the other tunnel
endpoint(s), are found. This capability allows for the dynamic
addition and removal of tunnels at a router.
Reichmeyer, et.al. Expires - May 2002 5
draft-franr-tunman-endpoint-config-00.txt November 2001
To implicitly discover and identify the endpoints of any given tunnel
facility that is to be deployed over a public IP infrastructure,
Tunnel Service Ids must be globally unique. They may take a number of
different forms, depending on the discovery mechanism used. See
sections below for discussion on various endpoint discovery
mechanisms and the configuration information associated with them.
Tunnel Service Id information should be updated at the necessary
devices as required by the particular mechanism used.
Configuration of which discovery mechanism is to be used must be
coordinated with the Tunnel Service Id information. That is, when
using implicit endpoint discovery, the endpoint must know, for a
given service identifier, which discovery mechanism to use to find
other endpoints. This information may be provided at the same time as
the service identifier, thus allowing the specification of a
potentially different mechanism for each configuration, or it may be
configured separately, as a default mechanism to use for all tunnels.
The choice may ultimately depend on whether a provider supports one
or more discovery mechanisms within its management domain and/or the
need for interoperability among administrative domains.
In addition to the choice of tunnel endpoint identification
mechanism, devices must be configured with information about the
signaling protocol and/or mechanisms to be used to establish the
tunnel. For example, if an IPsec tunnel is to be used, each endpoint
must be configured with key management and authentication mechanism
so that key exchange can occur; or if an MPLS tunnel is to be
established, all endpoints need to be configured with label
distribution protocol information (LDP or RSVP-TE) to correctly
establish the LSP tunnels. In the explicit identification case, the
tunnel signaling protocol information is provided when the tunnel
endpoints are provisioned. In the implicit case, it may be provided
at the same time as the Tunnel Service Id, thus allowing the
specification of a different signaling protocol for each tunnel; it
may be configured separately, as the default signaling to use for all
tunnels; or it may be obtained via the discovery mechanism itself, if
supported by the mechanism.
Upon discovering all enpoints for the tunnel(s), the configured
signaling protocol is invoked to establish the necessary tunnels. At
the time of creation, each tunnel is identified with a locally unique
Tunnel Id.
In the following sections, we discuss various dynamic endpoint
identification mechanisms and the configuration information
associated with them. The particular advantages and/or disadvantages
of using a particular mechanism are beyond the scope of this
document.
4.1 DNS
Reichmeyer, et.al. Expires - May 2002 6
draft-franr-tunman-endpoint-config-00.txt November 2001
The use of DNS to discover routers that serve participating sites of
a particular VPN has been proposed in [9]. This method is based on
resolution of a hierarchical naming scheme (i.e. an URL), that
uniquely identifies the VPN (VPN Id), to a set of addresses for the
routers in that VPN. In the context of tunnel management, the VPN Id
acts as the Tunnel Service Id and the resloved router addresses
equate to the endpoints for the tunnel(s) used to implement that VPN.
The use of DNS as described in [9] separates endpoint discovery from
tunnel signaling protocols and there is no recommendation to include
tunnel signaling protocol information in the DNS record along with
VPN identifier. Thus, the tunnel signaling protocol must be
provisioned separately, either at the time the Tunnel Service Id is
configured or as a default for all tunnels. That signaling protocol
is used to establish the necessary tunnel(s) and a Tunnel Id is
assigned according to the protocol used.
4.2 BGP/IGP Routing Protocols
TBD
4.3 LDAP (Directory Services)
TBD
5. Route Binding
In this section, we discuss the binding of static routes and the
binding of BGP and IGP VRs to tunnel endpoints. Since there are some
instances where tunnels are set up before the routes/VRs are bound
and other instances where the VRs set up the tunnels, the sequence
should be covered in a separate section. This section should just
focus on the need for routing to determine the best tunnel, the types
or routing mechanisms, and the means for provisioning them.
After identifying the participating devices, it is necessary that
they are able to establish the proper tunnels. In particular, this
means that paths must be established between the participating
devices for the purpose of carrying the data entitled to be conveyed
by the tunnel. This implies the need for provisioning the
participating devices with the appropriate routing information,
including IGP metrics as well as the reachability information for
accessing networks across domains through the tunnel. As an example,
Reichmeyer, et.al. Expires - May 2002 7
draft-franr-tunman-endpoint-config-00.txt November 2001
there are different ways of establishing this binding between the
endpoints and IP VPN tunnels:
- static configuration
- MPLS; RSVP-TE, LDP/CR-LDP
- BGP
- IGP
5.1 Static Route Binding
Static route binding is a static policy that directs all traffic
matching specific criteria to a specific tunnel. The criteria are
almost always the destination IP address (or subnet), as well as
additional fields to provide more granular control, such as the
DSCP/TOS field or a UDP/TCP port. This particular aspect of tunnel
management illustrates the immediate and compelling value of
utilizing the existing DiffServ informal model. In the DiffServ model,
classifiers can be specified that allow a unique datapath to be
defined for traffic matching provisioned criteria. Since a specific
datapath can include both tunnel encapsulation semantics and/or
deencapsulation semantics, static route bindings can quickly and
easily be constructed simply by adding encapsulation and
deencapsulation semantics to the informal model.
Note that this draft does not propose to alter the DiffServ informal
model or the DiffServ MIB or PIB specifications. Rather, this draft
seeks to build on the semantics defined in these documents to
integrate the QoS semantics and the tunneling semantics in a
consistent and cross-functional manner. Figures 1 & 2 illustrate how
we achieve this objective.
Suppose that a router has already been configured to provide two
classes of service for all traffic to a particular destination. Class
1 specifies that all Voice traffic within a profile of 300Kb should
be assigned the EF DSCP and any packets exceeding the profile should
be dropped. For Class 2 all EDI traffic within a profile of 400Kb
should be assigned DSCP AF11 and all EDI traffic above 400Kb should
be assigned a DSCP of AF12. Finally all remaining traffic within a
profile of 500Kb should be assigned a DSCP of AF12 and all out of
profile traffic should be assigned a DSCP of AF13. The result of this
particular configuration is that Voice traffic (within the profile)
will always get through. Further, all AF1 (Class 2) traffic will
normally get through if there is no congestion in the network.
However, in the event of congestion, all non-EDI traffic will be
impacted first and in sever congestion, only EDI traffic will make it
through. The actual representation for this model is shown in Figure
1.
+----------+
|Classifier|
Reichmeyer, et.al. Expires - May 2002 8
draft-franr-tunman-endpoint-config-00.txt November 2001
| Id=Net1 |
| ClfrId=12|
+----------+
+-----------+ +------------+ +-----------+ +--------+
|ClfrElement| |Meter | |Marker | |Queue |
| Id=EF | | Id=EF | | Id=EF | | Id=EF |
| ClfrId=12 | | SucceedNext+----->| Next +-->| Next +-->..
| Next +--->| FailNext +---+ | DSCP=46 | | Params |
| Filter | | Profile | | +-----------+ +---+----+
+----+------ + + -----+------+ | |
| | V V
V V + --------------+ +--------------+
+-----------+ +------------+ |Dropper | |QParams |
|Filter | |Profile | | Type=Absolute| | Id=EF |
| Id=EF | | Id=EF | +--------------+ | Type=Priority|
| DPort=VoIP| | Type=Simple| | Priority=1 |
+-----------+ | Rate=300Kb | +--------------+
+------------+
+-----------+ +------------+ +----------+
|ClfrElement| |Meter | |Marker |
| Id=EDI | | Id= EDI | | Id=EDI-1 |
| ClfrId=12 | | SucceedNext+--->| Next +------+
| Next +--->| FailNext +-+ | DSCP=10 | |
| Filter | | Profile | | +----------+ |
+----+------+ +-----+------+ | |
| | | |
V V | +----------+ |
+-----------+ +------------ | + |Marker | |
|Filter | |Profile | | Id= | EDI-2 | |
| Id=EDI | | Id=EDI | +- | > Next +---+ |
| DPort=EDI | | Type=Simple| | DSCP=12 | | |
+-----------+ | Rate=400Kb | +----------+ | |
| Burst=10Kb | | |
| Interval=10| | |
+------------+ | |
| |
+-----------+ +------------+ +-----------+ | | +-------+
|ClfrElement| |Meter | |Marker | | +->|Queue |
| Id=Else | | Id=Else | | Id=Else-2 | +---->| Id=AF1|
| ClfrId=12 | | SucceedNext+--->| Next +------->| Next +->..
| Next +--->| FailNext +-+ | DSCP=12 | +-->| Params|
| Filter | | Profile | | +-----------+ | +---+---+
+----+------+ +-----+------+ | | |
| | | | V
V V | +-----------+ | +----------+
+-----------+ +------------+ | |Marker | | |QParams |
|Filter | |Profile | | | Id=Else-3 | | | Id=AF1 |
| Id=Else | | Id=Else | +->| Next +----+ | Type=WFQ |
+-----------+ | Type=Simple| | DSCP=14 | | Rate=1Mb |
| Rate=500Kb | +-----------+ +----------+
Reichmeyer, et.al. Expires - May 2002 9
draft-franr-tunman-endpoint-config-00.txt November 2001
Figure 1. +------------+
In Figure 1, there is a clear delineation between the relationships
between the datapath components (Classifier to Meter, Meter to Marker,
etc.) and the structures necessary to provision each component. The
profile is separated from the Meter and the Filter is separated from
the Classifier. The benefit is not only that the configuration
elements can be reused across multiple datapaths but also that the
datapath is more clearly identified. This is particularly valuable
when considering the complexities and variations in configuring
tunnels.
Tunnels all share an encapsulation strategy, but the details of the
protocols vary considerably. Hence the approach of defining a simple
encapsulation or de-encapsulation datapath element and having it
point to a secondary object that describes the details of the
specific protocol is both a convenient abstraction strategy and also
integrates cleanly into the existing datapath configuration
architectures defined in the DiffServ working group. Figure 2
demonstrates this with the introduction of two new objects that
describe an encapsulation using 802.1q VLANs. We use VLANs here
because they are easy to represent. A MplsEncap object could be used
in place of the 802.1qEncap and will be specified in a future version
of this document. In Figure 2, the ClfrElements are not shown to
simplify the diagram.
+------------+ +----------- + + -----------+ +--------+
|Meter | |Marker | |TunEncap | |Queue |
| Id=EF | | Id=EF | | Id=EF | | Id=EF |
| SucceedNext+----->| Next +-->| Type=VLAN | | Next +->..
-->| FailNext +--- + | DSCP=46 | | Next +-->| Params |
| Profile | | +-----------+ | TunParams | +---+----+
+-----+------+ | +---+-------+ |
| V | V
V +--------------+ V +--------------+
+------------+ |Dropper | ------------ + + |QParams |
|Profile | | Type=Absolute| |802.1qEncap | | Id=EF |
| Id=EF | +--------------+ | Id=EF | | Type=Priority|
| Type=Simple| | VLANID=12 | | Priority=1 |
| Rate=300Kb | | DestMac= | +--------------+
+------------+ | Priority=6 |
+------------+
+------------+ +----------+
|Meter | |Marker |
| Id=EDI | | Id=EDI-1 |
| SucceedNext+--->| Next +-----+
-->| FailNext +-+ | DSCP=10 | |
| Profile | | +----------+ |
+-----+------+ | |
| | |
Reichmeyer, et.al. Expires - May 2002 10
draft-franr-tunman-endpoint-config-00.txt November 2001
V | +----------+ |
+------------+ | |Marker | |
|Profile | | | Id=EDI-2 | |
| Id=EDI | +->| Next +---+ |
| Type=Simple| | DSCP=12 | | |
| Rate=400Kb | +----------+ | |
| Burst=10Kb | | |
| Interval=10| | |
+------------+ | |
| |
+------------+ +-----------+ | | +----------+ +-------+
|Meter | |Marker | | +-> Tun | Encap | |Queue |
| Id=Else | | Id=Else-2 | +--- | > Id=AF1 | | Id=AF1|
| SucceedNext+--->| Next +------>| Type=VLAN| | Next +->..
-->| FailNext +-+ | DSCP=12 | +->| Next +-->| Params|
| Profile | | +-----------+ | | Tun Params| +---+---+
+-----+ + ------ | | +---+------+ |
| | | | V
V | +-----------+ | V +----------+
+------------+ | |Marker | | +------------+ |QParams |
|Profile | | | Id=Else-3 | | |802.1qEncap | | Id=AF1 |
| Id=Else | + >| Next +---- - + | Id=AF1 | | Type=WFQ |
| Type=Simple| | DSCP=14 | | VLANID=12 | | Rate=1Mb |
| Rate=500Kb | +-----------+ | DestMac= | +----------+
+------------+ | Priority=4 |
Figure 2 +------------+
After considering how cleanly the QoS and tunneling semantics can be
merged into a single management model the question remains how static
routes can be implemented within this model. In reality, the example
in Figure 2 is a form of static route. Rather than using IP addresses
to determine the encapsulation and routing rules, we are using the
Application and QoS criteria to determine the encapsulation rules.
While we are not determining the path taken through the network, we
are determining how the traffic will be isolated. If we really wanted
to determine the actual destination, we would assign the DestMac
field explicitly. Further, if a static route needed to be assigned
that specified how a set of addresses would be routed, we could add
this capability simply by adding an additional classifier in the
datapath that determined the target address based on the specific
classification criteria. Figure 3 shows a simplified version of the
earlier example. In Figure 3, only the AF1 portion of the model is
shown and the Meter and Marker elements are not shown to simplify the
diagram.
Marker
EDI-1
------+ +-----------+ +----------+
| |ClfrElement| |TunEncap |
| | Id=Path1 | | Id=Path1 |
| | ClfrId=13 | | Type=VLAN|
Reichmeyer, et.al. Expires - May 2002 11
draft-franr-tunman-endpoint-config-00.txt November 2001
| | Next +--->| Next +---+
| | Filter | | TunParams| |
Marker| +----+------+ +---+------+ |
EDI-2 | | | |
--+ | V V |
| | +-----------+ +-------------+ |
| | |Filter | |802.1qEncap | |
| | | Id=Path1 | | Id=Path1 | |
| | | DAddr=XXXX| | VLANID=12 | |
| | +-----------+ | DestMac=xxxx| |
| | | Priority=4 | |
| | +-------------+ |
| | |
| | +----------+ +-----------+ +----------+ | +-------+
| +-> |Classifier| |ClfrElement| |TunEncap | | |Queue |
+----->| Id=Route1| | Id=Path2 | | Id=Path2 | +-->| Id=AF1|
Else-2-- | ClfrId= > 13| | ClfrId=13 | | Type=VLAN| | Next +-
>..
+-> | | | Next +--->| Next +------>| Params|
| +----------+ | Filter | | TunParams| +---+---+
| +----+------+ +---+------+ |
| | | V
| V V +---------
-+
| -----------+ + +-------------+ |QParams
|
Else-3| |Filter | |802.1qEncap | | Id=AF1
|
------+ | Id=Path2 | | Id=Path2 | | Type=WFQ
|
| DAddr=YYYY| | VLANID=12 | | Rate=1Mb
|
+-----------+ | DestMac=yyyy| +---------
-+
| Priority=4 |
Figure 3 +-------------+
As Figure 3 shows, the insertion of a classifier in between the
Marker and the Queue allows Static route functionality to be easily
incorporated into the model. As such, the classifier (Net1) in Figure
1 acted as a demux point for different application types and the
classifier (Route1) acts as a demux point for unique static routes.
In this example, the ClfrId of 13 specifies a list of classifier
elements that share the same ClfrId. Logically this means that all
traffic matching the Destination IP address of XXXX will follow the
upper datapath and the traffic matching the Destination IP address of
YYYY will follow the lower datapath. Additional datapaths can be
added by adding new classifier elements with a ClfrId of 13. More
details on how to specify static routes and how to construct tunneled
datapaths are specified in [4].
5.2 Dynamic Route Binding
Reichmeyer, et.al. Expires - May 2002 12
draft-franr-tunman-endpoint-config-00.txt November 2001
The major distinction between dynamic routing and static routing is
that a constantly changing routing table is involved in making
forwarding decisions. Because these dynamically updated routes
influence the destination ports as well as multiple headers (L2 and
Tunneled L3) for a packet, a generalized mechanism must be supplied
that can pass route information such as the target termination point
from the routing engine to the datapath elements.
The COPS framework PIB offers a solution in the form of a preamble
marker and preamble classifier. The preamble marker is an element
that associates a string with the packet. Multiple instances of a
preamble marker element can be chained together to associate multiple
strings. A preamble classifier element is a specialized classifier
that specifically matches strings associated with specific packets.
The purpose of the preamble is to allow previously learned
information, such as L2 headers or overwritten DSCPs or whether a
packet was in profile or not to, be carried with the packet so that
subsequent datapath elements can reuse the information to make
appropriate decisions. This capability is particularly valuable for
implementation-specific information carried across many fabric
implementations. The main reason why strings are used is because the
information that is carried is so implementation specific. For
instance, if a specific implementation is capable of remembering VLAN
Id on the ingress L2 header, passing that information with the packet
to the egress port and then assigning the same or equivalent VLAN on
the egress L2 header, we use can use the Preamble Marker on the
ingress datapath and the Preamble Classifier on the egress datapath
to express this capability.
The reason why preambles are so useful for addressing dynamic route
bindings is that we can use preambles to map router semantics to
datapath semantics. Figures 4 and 5 show this is done by describing 3
tunnels (2 termination points with one tunnel supporting 2 QoS
levels) that share an egress port (datapath). In the example, the
preambles are used to determine the appropriate termination point.
Figure 4 shows how the PreambleFilter is used to identify termination
address specified by the routing table. Figure 5 shows how additional
classifiers behind the preamble classifier can be used to key off of
the DSCP in the packet to choose the tunnel with the appropriate QoS
level for the specific termination point. It is worth noting that
although unique tunnels are assigned to each termination point and
QoS level, the example shows how tunnels to different termination
points can be recombined to receive the same QoS treatment in the
local system. It is also worth noting that this example uses the IP
address of the termination point in the preamble. Since the Preamble
is a string, other conventions such as Termination point ID or
Termination Label could also be used and are assumed to be
implementation specific.
+-----------+
Reichmeyer, et.al. Expires - May 2002 13
draft-franr-tunman-endpoint-config-00.txt November 2001
|ClfrElement| +-----------+
| Id=TP1 | |Classifier |
| ClfrId=21 | | Id=TP1 |
| Next +--->| ClfrId=77 |
| Filter | +-----------+
+----+------+
|
V
+------------+
|PreamFilter |
| Id=TP1 |
+-----------+ | Str=1.1.1.1|
|Classifier | +------------+
| Id=TP |
| ClfrId=21 |
+-----------+ +-----------+
|ClfrElement| +-----------+
| Id=TP2 | |Classifier |
| ClfrId=21 | | Id=TP1 |
| Next +--->| ClfrId=88 |
| Filter | +-----------+
+----+------+
|
V
+------------+
|PreamFilter |
| Id=TP2 |
| Str=2.2.2.2|
+------------+
Figure 4.
Reichmeyer, et.al. Expires - May 2002 14
draft-franr-tunman-endpoint-config-00.txt November 2001
+-----------+ +------------+
|ClfrElement| |TunEncap |
| Id=TP1EF | | Id=TP1EF | +-------+
| ClfrId=77 | | Type=MPLS | |Queue |
| Next +--->| Next +---------->| Id=EF |
| Filter | | TunParams | | Next +-->..
+----+------+ +-----+------+ | Params|
| | +---+---+
V V |
+-----------+ + - ----------- -+ V
|Filter | |MPLSTunParams| +--------------+
| Id=TP1EF | | Id=TP1EF | | QParams |
| DSCP=46 | | ... | | Id=EF |
+-----------+ +-------------+ | Type=Priority|
| Priority=1 |
+-----------+ +------------+ +--------------+
|ClfrElement| |TunEncap |
| Id=TP1AF | | Id=TP1AF |
| ClfrId=77 | | Type=MPLS |
| Next +--->| Next +------+
| Filter | | TunParams | |
+----+------+ +-----+------+ | +-------+
| | | |Queue |
V V +--->| Id=AF |
+--------------+ +-------------+ | Next +->..
|Filter | |MPLSTunParams| +--->| Params|
| Id=TP1AF | | Id=TP1AF | | +---+---+
| DSCP=10,12,14| | ... | | |
+--------------+ +-------------+ | V
| +----------+
+-----------+ +------------+ | |QParams |
|ClfrElement| |TunEncap | | | Id=AF |
| Id=TP2AF | | Id=TP2AF | | | Type=WRR |
| ClfrId=88 | | Type=MPLS | | | Weight=30|
| Next +--->| Next +------+ +----------+
| Filter | | TunParams |
+----+------+ +-----+------+
| |
V V
+--------------+ +-------------+
|Filter | |MPLSTunParams|
| Id=TP2AF | | Id=TP2AF |
| DSCP=10,12,14| | ... |
+--------------+ +-------------+
Figure 5.
The details for the Tunneling parameters are not specified in figure
5 because they have not been defined in this version of the draft. It
is highly likely that there will be multiple Tunnel Parameter classes
defined to deal with various configuration strategies mentioned at
the beginning of this section.
Reichmeyer, et.al. Expires - May 2002 15
draft-franr-tunman-endpoint-config-00.txt November 2001
It is worth noting that although Preamble datapath elements are
currently only specified for COPS, these structures can also be
defined with MIBs making this solution viable for both SNMP and COPS-
based management environments.
6. CE vs. PE Configurations
Depending on whether the devices being configured as tunnel endpoints
are located on the customer premises (CE) or in the provider network
(PE), there may be considerations related to configuration,
mechanisms, protocols, etc.
TBD
7. Security Considerations
TBD
8. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 C. Jacquenet, et.al., " Requirements for Dynamic Tunnel
Configuration", draft-jacquenet-tunman-rqts-00.txt, work in
progres
4 K. Chan, et.al., "Tunnel Management Data Path", draft-chan-tunman-
datapath-00.txt, work in progress
5 T. Choi, et.al., "Tunnel Management Statistics", draft-choi-
tunman-stats-00.txt, work in progress
6 M. Carugi, et.al., "Service Requirements for Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-requirements-02.txt
7 D. Awduche, et.al., "A Framework for Internet Traffic
Engineering", draft-ietf-tewg-framework-04.txt
8 Y. Bernet, et.al., "An Informal Management Model for Diffserv
Routers", draft-ietf-diffserv-model-06.txt
9 J. Luciani, et.al., "Using DNS for VPN Discovery", draft-luciani-
ppvpn-vpn-discovery-00.txt
Reichmeyer, et.al. Expires - May 2002 16
draft-franr-tunman-endpoint-config-00.txt November 2001
9. Acknowledgements
10. Author's Addresses
Francis Reichmeyer
PFN
Phone: +1 203 668 0008
E-Mail: franr@pfn.com
Walter Weiss
Ellacoya Networks
7 Henry Clay Drive
Merrimack, NH 03054
Phone: +1 603 879 7364
E-Mail: wweiss@ellacoya.com
Reichmeyer, et.al. Expires - May 2002 17