Internet DRAFT - draft-franr-tunman-endpoint-config

draft-franr-tunman-endpoint-config




                                                        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