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