INTERNET DRAFT Bernhard Suter Category: Standards Track Ping Pan Title: draft-pan-cops-te-00.txt Bell Labs Date: June 1999 COPS Extension for Intra-Domain Traffic Engineering Status of this Memo This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract COPS [COPS] is a Policy Transport protocol that can be used for exchanging resource allocation commands between PDP and PEP [COPSFRAME]. This memo defines COPS messages and objects for supporting Traffic Engineering and resource management functionality at network edge routers. The work defined in this memo is motivated by the recent activities in Internet-2 QBone and IETF AAA and RAP working groups. Suter, Pan expires December 1999 [Page 1] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 1 Introduction The objective in this memo is to define a communication mechanism between PDP's and PEP's which can be used to provide traffic engineering functionality within an ISP's network. 1.1 Network Model Figure-1 illustrates a sample network. +------------------+ | PDP | +------------------+ ^ ^ | | +---------------+ +---------------+ | | | | v v +----------+ +----+ +----+ +----+ +----------+ ==>| Edge Rt1 |-----| R1 |-----| R2 |-----| R3 |-----| Edge Rt2 |==> | / PEP1 | +----+ +----+ +----+ | / PEP2 | +----------+ +----------+ | | | +----+ +----+ +----+ | +-------| R4 |-------| R5 |-------| R6 |-------+ +----+ +----+ +----+ Figure 1: Sample Backbone Network Configuration Rt1 and Rt2 are the edge/border routers in an ISP domain. User traffic enters the network at Rt1 and exits at Rt2. As a transit network, the ISP can set up multiple "virtual" tunnels between Rt1 and Rt2. The tunnel setup mechanism can be RSVP[RSVP], RSVP-LSP extension[RSVP-LSP] or other means. Network resource allocated to each tunnel can be described in terms of bandwidth, traffic class[DIFFSERV] and/or MPLS labels[MPLS]. As shown in the figure, there could be multiple routes between R1 and Rt2. In this case, both R1-R2-R3 and R4-R5-R6 can be used to carry traffic across the ISP backbone. For redundancy, one of them can be used as the backbone tunnel. In the example, when Rt1 detects a tunnel failure on R1-R2-R3, it can redirect the traffic to R4-R5-R6 Suter, Pan expires December 1999 [Page 2] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 tunnel. To provide traffic engineering functionality, we assume that the edge routers are controlled by Policy Servers (that is, PDP's as being defined in [COPSFRAME]). The communication between PDP's and PEP's uses COPS protocol. Policy Servers distributes resource allocation policy information to the edge routers. To comply with the policy, the edge routers (or PEP's) may trigger tunnel setup protocols to create/modify/delete virtual tunnels, and interface with router's forwarding path or routing database to implement filters to assign traffic to a specific tunnel. The PEP's need to notify the PDP's in case of tunnel changes. 1.2 Components This memo defines two major policy components: tunnels and filters. 1. A tunnel is a means of forwarding packets from one point to another in a network which appear to be virtually connected by this tunnel. Tunnels are unidirectional and have a defined ingress and egress node and depending on the type of tunnel, may have additional parameters like bandwidth reservation or specified route. Supported types of tunnels can be MPLS label paths, IP-in- IP tunnels, DiffServ trunks, RSVP flows, ATM or Frame Relay logical interfaces or anything else that satisfies the above description. 2. A filter is a means of selecting packets to be forwarded through a tunnel. Filter rules may be based on fields of the packet headers, routing protocol information or properties of the incoming L2 interface. Packets are forwarded based on the first matching filter rule. Filters have a priority that can be used to resolve ordering problems where they arise. The priority among different types of filters is implementation dependent. A filter can be associated with an ordered list of tunnels, packets will be forwarded to the tunnel with the highest preference level in this list. Supported types of filters can include incoming MPLS labels, ATM or Frame Relay circuits, packet classifiers, incoming DiffServ codepoints, BGP attributes, etc. Suter, Pan expires December 1999 [Page 3] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 Supporting traffic engineering implies the following: 1. PDP's need to be able to request PEP's (ingress nodes) to set up tunnels with specified properties within the network. Traffic engineering decisions may be unsolicited and triggered by user policy update on the PDP. The PDP may specify source route or explicit route objects to implement QoS or constraint based routing and path selection policies. 2. PDP's need to be able to configure PEP's to forward incoming data traffic onto these tunnels by specifying various kinds of filters with associations to these tunnels. Each tunnel or filter rule is considered a policy element or object and assigned a unique ID by the PDP. This ID is used by the PDP to modify or uninstall a policy element or create associations among them (e.g. associate filters with tunnels) and by the PEP to report status changes of a policy element. The policy element ID is orthogonal to the COPS client handle, which identifies a client request context. 1.3 Disclaim and Assumptions DIAMETER [DIAMETERFRAME, DIAMETER] can also be used to transfer policy information between PDP's and PEP's. This extension can be easily modified to interface with DIAMETER as well. Until various IETF working groups have resolved their differences on policy requirements, we will use COPS for traffic engineering support. Further, the scope of this draft is limited by the following assumptions: o We do not describe the operation of the tunnel setup protocols. However, by design, the extension will work with [RSVP-LSP]. o We do not specify the definition of tunnels, which can be RSVP flows, MPLS tunnels, DiffServ trunks, etc. Our goal is to support any tunnel descriptors between PDP's and PEP's. 1.4 Specification of Requirements Suter, Pan expires December 1999 [Page 4] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 In this document, several words are used to signify the requirements of the specification as defined in [REC]. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2. Extension Specific Object Formats The object format follows the convention defined in [COPS]. 2.1 TUNNEL_ID Object The TUNNEL_ID object encapsulates a unique value that identifies a tunnel. The identification is assigned by the PDP, and is 4-byte long. The tunnel id is used by the PDP to create, modify or withdraw tunnel policy objects of specified type and by the PEP for error or status reports regarding a specific tunnel. C-Num = 30 C-type = 1, "Classical" RSVP tunnel C-type = 2, RSVP LSP tunnel C-type = 3, DiffServ Trunk C-type = 4, IP-IP tunnel Suter, Pan expires December 1999 [Page 5] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 The object has the following context. +-------------+-------------+-------------+-------------+ | Tunnel Id value | +-------------+-------------+-------------+-------------+ 2.2 TUNNEL_PREF Object This object is used to describe the relative priority level of a tunnel associated with a filter. A filter policy may contain a list of pairs of tunnel Id and tunnel preference objects. The PEP MUST send traffic matching this filter rule to the available tunnel with the highest preference level. If multiple tunnels are listed with the same highest eligible preference levels, the PEP MAY do load sharing among them or pick one at random. Note that the preference is not a property of the tunnel policy, but of the association or binding of a tunnel to a filter policy. E.g. two tunnels may implement 2 different service classes to the same egress node and serve as each others standby in case of failure of one of the tunnels. C-Num = 31 C-type = 1 The object has the following context. +-------------+-------------+-------------+-------------+ | Preference Levels | Flag | +-------------+-------------+-------------+-------------+ The lowest preference level is 0, and the highest is 0xffff. Flag: Don't Care = 1 Suter, Pan expires December 1999 [Page 6] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 2.3 DSCP Object The DSCP Object defines the Differentiated Services Code Point associated with a tunnel. The tunnel is represented by a diffServ trunk and results in its packets being marked with the indicated DSCP. C-Num = 32 C-type = 1, DiffServ Code Point The object has the following context. +-------------+-------------+-------------+-------------+ | DSCP Value | Padding | +-------------+-------------+-------------+-------------+ 2.4 BANDWIDTH Object It is used to defined the bandwidth associated with a tunnel. The BANDWIDTH Object may be used along with the DSCP Object to define a DiffServ "trunk" in a network. Alternate bandwidth request description objects may be used in accordance with the signaling protocols and networks services used (E.g. IntServ). C-Num = 33 C-type = 1 The object has the following context. +-------------+-------------+-------------+-------------+ | Token Size | +-------------+-------------+-------------+-------------+ | Measurement Interval | +-------------+-------------+-------------+-------------+ The value of Token Size is the maximum number of bytes that can be Suter, Pan expires December 1999 [Page 7] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 transmitted per interval on a particular tunnel. The bandwidth of a tunnel is given by (Token Size)/(Measurement Interval). 2.5 FILTER_ID Object The FILTER_ID Object encapsulates a unique value that identifies a filter. The identification is assigned by the PDP, and is 4-byte long. The filter id is used by the PDP to create, modify or withdraw filter policy objects of specified type and by the PEP for error or status reports regarding a specific tunnel. C-Num = 34 C-type = 1 The object has the following context. +-------------+-------------+-------------+-------------+ | Filter id | +-------------+-------------+-------------+-------------+ 2.6 FILTER Object The FILTER Object is used to set up ingress packet classification at edge routers. Several types of filters are defined here. They are differentiated by the C-type of the object. C-Num = 35 C-type = 1 packet classification C-type = 2 MPLS LSP C-type = 3 BGP Path Attributes Each FILTER Object has a common header and multiple sub-objects that Suter, Pan expires December 1999 [Page 8] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 provide detailed description of the filter. The format of the object is +-------------+-------------+-------------+-------------+ | Priority | Action of Last Resort | +-------------+-------------+-------------+-------------+ | | // Filter Content // | | +-------------+-------------+-------------+-------------+ Priority indicates the order of rules for a given filter entry. It is used for building up policy tables at the PEP. Filters with same priority do not have a defined order and MAY be ordered by the PEP in any order among each other. When all the tunnels associated with a filter are disabled, the router refers to the Action-of-Last-Resort to decide what to do. If tunnels are used to implement VPNs with private addressing, there might be no implicit default route to deliver the packets on a best effort basis. Action of Last Resort: 1. remove the filter; 2. best effort; 3. discard; o Packet Classifier Packet classifiers are rules based on combinations of fields in the IP and TCP or UDP headers. If the protocol is neither UDP or TCP, the port information MUST be ignored. Protocol set to zero indicates that the rule does not cover the IP protocol field. Fields with Min and Max value rules can be rendered insignificant by setting min to zero and Max to the maximum value (255 or 65535). IP address masks can only denote prefixes. A packet matches a rule if all the constraints of this rule are satisfied. +-------------+-------------+-------------+-------------+ Suter, Pan expires December 1999 [Page 9] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 | Destination IP Address | +-------------+-------------+-------------+-------------+ | Destination IP Address Mask | +-------------+-------------+-------------+-------------+ | Source IP Address | +-------------+-------------+-------------+-------------+ | Source IP Address Mask | +-------------+-------------+-------------+-------------+ | DSCP Min | DSCP Max | Protocol | Padding | +-------------+-------------+-------------+-------------+ | Dst Port Min | Dst Port Max | +-------------+-------------+-------------+-------------+ | Src Port Min | Src Port Max | +-------------+-------------+-------------+-------------+ o MPLS LSP The object content is a stack of LSP's. All incoming MPLS packets with this label stack will be assigned to a tunnel based on this filter. This may be useful, to terminate an MPLS tunnel and assign its traffic to a specific DiffServ trunk. +-------------+-------------+-------------+-------------+ | LSP # 1 | +-------------+-------------+-------------+-------------+ // ... // +-------------+-------------+-------------+-------------+ | LSP # N | +-------------+-------------+-------------+-------------+ o BGP Path Attributes This object applies to the BGP-speaking border routers. It can be used to direct inter-domain traffic within an ISP's network. +-------------+-------------+-------------+-------------+ | BGP Next-Hop | +-------------+-------------+-------------+-------------+ BGP Next-Hop is the IP address of a remote BGP-speaking border router. Suter, Pan expires December 1999 [Page 10] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 4. Additional Requirements in the Base Protocol The extension requires a new Client Type, 3. The PEP's and the PDP's that support this extension MUST be able to parse all the objects defined Section 2. Two new C-types are defined in the Client Specific Information Object (ClientSI): C-type = 3, for RSVP-LSP extension With this type ClientSI, the PDP and the PEP should encapsulate and understand a sequence of relevant RSVP objects such as EXPLICIT_ROUTE and SESSION_ATTRIBUTE objects. C-type = 4, for status report on policy elements In RPT messages, the PEP can send a sequence of policy element objects (such as TUNNEL_ID and FILTER_ID objects) along with a object to inform the status of tunnels and filters. A new C-type is defined in the Decision Object: C-type = 6, Traffic Engineering Server Specific Decision Data This decision serves as a container for all relevant tunnel and filter objects. Each tunnel or filter decision MUST start with a TUNNEL_ID or FILTER_ID, respectively. A tunnel decision MAY consists of any amount of descriptive objects such as DSCP, bandwidth as well as a ClientSI object, which in term MAY consist of RSVP objects for tunnel establishment. A filter decision MAY consist of a FILTER object and the information on the tunnels that are associated with the filter. A Traffic Engineering-specific Decision object may have the following format: Suter, Pan expires December 1999 [Page 11] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 ::= | ::= [] [] ::= [] [ ] ::= | Two new C-types are defined for the Report Type Object for status updates on installed policy elements: C-type = 8, Failed C-type = 9, Restored C-type = 10, Switched Failed is used by the PEP to indicate that a policy element which has previously been reported as Installed, has operationally failed due to network or device failure conditions. Restored is used to indicate that this failure condition has been resolved and that the policy element reverts back into a fully operational state. Switched is used to indicated that a policy object has performed a valid and preconfigured switchover operation due to a failure condition or restoration. (E.g a filter rule has changed its active tunnel to the most preferable among the active ones in its list of tunnel associations.) 5. Description of Operation 5.1 Initialization As being defined in COPS, at initialization time, the PEP sends OPN (Client-Open) messages to the PDP to inform about the client capability that the PEP can support and the PEP identification. It must send the new client-type (3). Suter, Pan expires December 1999 [Page 12] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 5.2 Policy Element Installation The operation required in this memo is very simple: the PDP sends tunnel setup commands and traffic classification rules to the PEP in COPS DEC (Decision) messages, using an Install decision flags command code. Each TE decision object defines one policy element and needs to contain sufficient information for the successful creation and activation of this object. The TUNNEL_ID contains a number generated by the PDP. The DSCP value inside the DSCP object is used to describe the traffic class of the tunnel inside the network. In current version, the ClientSI contains all possible RSVP objects that can be used to set up a LSP tunnel within the network. The C-type for the Decision must be 6. The PEP MUST acknowledge either installation of failure (Installed/NotInstalled) of each policy element by including its policy element ID in the clientSI object of a report message. For tunnels with a long expected setup time, the PEP MAY send a Commit report to the PDP to indicate that the policy element has been validated, local resources allocated and that setup is pending in the network. If a filter rule is successfully linked to an operational tunnel, its tunnel ID must be included as application object in the ClientSI object of the report message. If installation of a policy element depending on network conditions has failed, the PEP must report any application error to the PDP and retry periodically until the PDP removes the policy element. 5.3 Policy Elements Affected by Network State Changes Whenever the PEP detects changes in the operational state of any policy element, it MUST notify the PDP through additional report messages. Such state changes may include failure or restoration of tunnels or changes in association of traffic filters with tunnels. 5.4 Modification of Policy Elements Any additional Install decisions with an existing policy element ID is considered a modification. Any existing configuration state of the policy element in the PEP MUST be replaced with the content of the new decision object. The PEP must reply with an Installed/NotInstalled report on the policy element. If a Suter, Pan expires December 1999 [Page 13] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 modification has failed (NotInstalled) the PDP assumes that it has remained in its previous state. If the failed modification attempt has rendered the policy element inoperational, the PEP MUST report its failure. 5.5 Client Requested Creation of Policy Elements The PEP can also initiate a tunnel setup by sending a request to the PDP with a RSVP ClientSI which contains the necessary objects to describe a tunnel setup demand. The PDP may respond with a sequence of decisions objects to set up the necessary elements. All messages related to policy elements that are related to a client request MUST carry the client handle of the request. The server still picks unique TUNNEL_ID resp. FILTER_ID to identify each of the policy elements in any decision message. Deletion of this client handle by the PEP implicitly invalidates all policy element IDs associated within the context of this client handle. 6. Redundancy Consideration One important feature in traffic engineering is tunnel redundancy: if a tunnel goes down, its traffic should be sent using a backup tunnel. This requires the edge routers to setup and maintain multiple connections between two same ingress and egress edge routers. To allow fast switch-over, the PDP may associate a filter policy with multiple tunnels. Each of this associations has a precedence level. In case of a tunnel failure, the PEP should switch the traffic to the ones with lower preference levels. 7. On-line vs. Off-line Tunnel Setup In case of MPLS tunnel setup, the path can be determined offline by configuration servers or online by QoS routing. In case of offline path computation, the explict route information MUST be sent down in COPS DEC messages. The operation is outlined in Section 5.2. For online path computation, the PEP can determine the path dynamically, and MAY report the explict route information to the PDP for accounting purposes. Suter, Pan expires December 1999 [Page 14] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 8. Inter-domain Considerations Inter-domain tunnel request information could either be exchanged through the tunnel setup protocol at the domain border (see section 5.5). Or by means of additional protocols among PDPs which is beyond the scope of this memo. 9. Security Considerations The security requirements of the operations described in this memo must be covered by the COPS base protocol. Particularly it must ensure mutual authentication of PDP and PEP. Acknowledgments We would like to thanks Petri Aukia, Helena Sarin and Murali Kodialam for useful comments. Special thanks go to Pramod Koppol and T.V. Lakshman for many ideas and significent contributions. References [COPS] Boyle, J. et al., "The COPS (Common Open Policy Service) Protocol", Internet Draft, draft-ietf-rap-cops-06.txt, February 24, 1999. [COPSFRAME] Yavatkar, R. et al., "A Framework for Policy-based Admission Control", Internet Draft, draft-ietf-rap-framework-02.txt, April 1999. [DIAMETERFRAME] Zorn, G. et al., "DIAMETER Framework", Internet Draft, Internet Engineering Task Force, May 1998. [DIAMETER] Calhoun, P. et al., "DIAMETER Base Protocol", Internet Draft, draft-calhoun-diameter-07.txt, November 1998. [DIFFSERV] Blake, S. et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [RSVP] R. Braden, et al., "Resource ReSer-Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205, September 1997. [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels" , RFC2119, March 1997 Suter, Pan expires December 1999 [Page 15] INTERNET DRAFT draft-pan-cops-te-00.txt June 1999 [RSVP-LSP] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999 [MPLS] Callon, R. et al., "A Framework for Multiprotocol Label Switching", Internet Draft, draft-ietf-mpls-framework-02.txt, November 21, 1997. Author Information Bernhard Suter Bell Labs, Lucent 101 Crawfords Corner Road, Room 4C-526 Holmdel, NJ 07733 USA Phone: 732 949 8516 Email: suter@dnrc.bell-labs.com Ping Pan Bell Labs, Lucent 101 Crawfords Corner Road, Room 4C-508 Holmdel, NJ 07733 USA Phone: 732 332 6744 Email: pingpan@dnrc.bell-labs.com Suter, Pan expires December 1999 [Page 16]