Internet Draft Giacomo Sergio Document: draft-sergio-rap-cops-xcops-00.txt CPR Expires: July 2002 January 2002 Multiprotocol-DiffServ interworking using COPS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document introduces a new client type for the COPS protocol to support Multiprotocol-DiffServ inter-working in a network scenario where the access network is a non-DiffServ network. In such a scenario, traffic flows originating from heterogeneous applications ask to be admitted to the Diffserv core network. The Policy Decision Point (PDP) acts as a "Bandwidth Broker" for Policy Enforcement Points(PEP) requesting resources. The new client type is located on each Border Router (PEP) of the Diffserv Network. The purpose of the proposed client type is to translate the various access protocols in a common language by means of appropriate COPS extensions. It allows to implement a unified PEP type despite of the adopted access protocol, and a single COPS server (PDP) for the Diffserv network. It could be located inside the Bandwidth Broker itself,avoiding to refer to a higher-level device when performing resource allocation. Glossary BB Bandwidth Broker EE Edge Router Multiprotocol DiffServ interworking using COPS January 20022 COPS Common Open Policy Service. See [1] PDP Policy Decision Point. See PEP Policy Enforcement Point. See Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Glossary...........................................................1 1. Introduction ...................................................3 2. X-COPS values for COPS objects .................................5 2.1 Common Header, client type ...................................5 2.2 Context Object (Context) .....................................5 2.3 X-COPS Protocol Objects ......................................6 2.4 Request ID Object (ReqID) ....................................6 2.5 Source Host IPv4 address Object (SrcIP) ......................7 2.6 Destination IPv4 address Object (DstIP) ......................7 2.7 Source Host IPv6 address Object (SrcIPv6) ....................8 2.8 Destination IPv6 address Object (DstIPv6) ....................8 2.9 Ingress Border Router Interface Object/TrunkID (IPv4BRIf) ....9 2.10 Ingress Border Router Interface Object/TrunkID (IPv6BRIf) ...9 2.11 Egress Border Router Interface Object (IPv4ER) .............10 2.12 IPv6 Egress Border Router Interface Object (IPv6ER) ........10 2.13 Traffic Type Object (Ttype) ................................11 2.14 Traffic Characterization Object (Tchar) ....................11 2.14.1 Characterization Type 1 ..................................12 2.14.2 Characterization Type 2 ..................................12 2.14.3 Characterization Type 3 ..................................13 2.14.4 Characterization Type 4 ..................................13 2.14.5 Characterization Type 5 ..................................14 2.15 QoS Class Description Object (QoSDesc) .....................14 2.16 QoS Parameters Description Object (QoSPrms) ................15 2.17 X-COPS Decision Object (X-COPSDec) .........................15 2.18 Temporal information object (TempInfo) .....................16 2.19 Reject Reason Object (RejRea) ..............................17 3. X-COPS Client Specific Information Object (X-COPS ClientSI) ...17 3.1 X-COPS Client Specific RAR data .............................18 3.2 X-COPS Client Specific Decision data ........................19 4. Message content ...............................................20 4.1 Request Message (REQ) PEP -> PDP ............................20 4.2 Decision Message (REQ) PDP -> PEP ...........................20 4.3 Report State Message (RPT) PEP -> PDP .......................20 5. Security consideration ........................................21 References........................................................22 Author's Addresses................................................22 Multiprotocol DiffServ interworking using COPS January 20022 1. Introduction The COPS (Common Open Policy Service) [1] is a simple query and response protocol that can be used to exchange policy information in an administrative domain. Relying on the client-server model COPS architecture is based on two fundamental elements: a policy server, called Policy Decision Point (PDP), also addressed as COPS server, and one or more policy clients, called Policy Enforcement Points (PEPs), addressed as COPS clients. At least one policy server must exist in each administrative domain, in order to implement a complete COPS communication with one or more PEPs. A single PEP is able to support multiple client-types, and it may send multiple Client-Open messages to the PDP, each specifying a particular client-type to a PDP over one or more TCP connections. If a client-type is not supported by the PDP, the PDP itself can redirect the PEP to an alternative PDP address and port for a given client-type via COPS. In an advisable network scenario the peripheral non-Diffserv access networks, mainly IntServ networks with the RSVP signalling protocol but the approach could be generalized (H.323, SIP, MPEG-4, etc.), are connected to a Diffserv core network (as for the access network, the approach could be generalized to an MPLS core network). In such a scenario the key elements are the Edge and Border Routers, which manage the interoperability between diverse domains. In our proposal the functionality of both devices are unified within a single element called X-DiffServ Border Router (X-DS BR, where X is for a generic access network architecture, e.g. IntServ). Two orthogonal dimensions may be highlighted in the X-DS BR. The data plane (horizontal direction) provides the mapping and forwarding of the access network flows into the proper Diffserv PHBs and vice versa. The control plane (vertical direction) is responsible for Admission Control (AC) and policy decisions (taken on a per-flow or per-PHB basis) and for the service level agreement (SLA) maintenance. Focusing on the control plane, our proposal is to make the X-DS BR communicate with the BB by means of the COPS protocol, because of the great flexibility it provides and the possibility of encapsulating client-specific information in its messages. The X-DS BR may either delegate all AC and policy decisions to the BB, working in a totally outsourcing scenario, or may have limited local AC and policy functionality, granted by a provisioning scenario. In any case BB has pre-emption rights on each X-DS BR decision. According to the COPS architecture, the X-DS BR must provide an interface to the BB (i.e. the COPS client, or PEP) to send requests, accept decisions and periodically report its status. The BB, which is able to monitor the network status works as an "oracle", performs the centralized AC and policy functionality. Multiprotocol DiffServ interworking using COPS January 20022 It is possible (e.g. in MPLS Core Networks) that the BB configures core and border elements according to its choices, achieving traffic engineering capabilities. So, BB in its turn must provide for an interface with the X-DS BR to accept requests and send decisions (i.e. the PDP, or COPS server) and should have one or more interfaces towards the core network to collect NE status and send NE configuration data. As previously addressed, it is desirable to tune an optimum mix of dynamical and static resource allocation in order to share architectural complexity between BB module and border NEs and make the system scalable. Our proposal focuses on the possibility of integrating diverse protocols used in the Access Network. In a general scenario applications speaking different "languages" may coexist, and the access point of the Core Network, that is the X-DS Border Router, must understand all these languages. As said, the protocol chosen to allow communication between X-DS Border Router and the Bandwidth Broker is COPS. According to the COPS architecture, different applications using different protocols may be viewed as different client types. A client type is already defined for the integration of RSVP and COPS [2], where RSVP is COPS client-type 1. The proposed standard has some weak points due to the nature of RSVP itself. For example, the duplication of the states installed both in PDP and in PEP limits the scalability of the model and the possibility of expanding the core domain. A possible solution to this scalability problem is an administrative domain with many PDP supporting one or few client-types each. Whenever a PEP sends a client-open message to a PDP that does not support that client-type, it has the capability to redirect the PEP to the right PDP. This solution is more scalable but needs to develop many COPS servers, one for each of the supported client- types within the domain. All these COPS servers have to exchange management information to perform a coherent resource allocation, or they must query for a higher level "omniscient" BB. Starting from the above-mentioned considerations, we propose to develop a unified COPS semantic able to integrate all the different protocols supported by the access domain. This semantic will encapsulate the client-specific information in a common format apart from the specific protocol. By means of this modified architecture it is possible to reduce the complexity of the system: The X-DS BR traduces the incoming requests in a common format; A unified COPS client-type is able to transmit all the information to the PDP; It is no longer needed to develop a different COPS server (PDP) for each supported COPS client; Multiprotocol DiffServ interworking using COPS January 20022 There is no need to refer to a higher-level device when performing resource allocation because the unique COPS server (PDP) could be located inside the BB itself. For this purpose, a new client-type, the X-COPS client type, is defined in the following sections. This client-type is used to transport admission control messages despite of the signalling protocol (e.g. RSVP, SIP, H.323) and from the QoS protocol (e.g. DiffServ/MPLS). Therefore a single client could be supported by the PDP while the complexity is shifted on the border router where a appropriate Inter Workin Unit (IWU) is used to map protocol specific messages into generalized client messages. In order to perform policy decision and admission control for a certain traffic flow, the Bandwidth Broker, needs to know the following set of information concerning the traffic flow itself: Origin: which host originated the flow; which border router interface the traffic will pass from; Direction: which is the egress border router for the traffic flow; which core routers the traffic flow will go across; Traffic type (in terms of traffic characterization and QoS parameter specification); Temporal information (e.g. start time, end time, repetition intervals); Apart from the specific signalling protocol used by the clients, some of these information need to be passed from the PEP to the PDP by means of the X-COPS client type, while others will be somehow learned by the Bandwidth Broker. 2. X-COPS values for COPS objects The meaning and usage of several COPS objects is affected when used with the X-COPS client type. This section describes these objects and their usage. 2.1 Common Header, client type X-COPS is COPS client-type TBD. 2.2 Context Object (Context) Multiprotocol DiffServ interworking using COPS January 20022 The semantics of the Context object for X-COPS is as follows: R-Type (Request Type Flag) R-Type = 0x01: Incoming-Message/Admission Control Requests; R-Type = 0x02: Resource Allocation Request; R-Type = 0x08: Configuration request; For the X-COPS client-type the R-Type flag 0x04 (Outgoing- Message Request) is not used. M-Type (Message Type) The M-Type field in the Context Object is used to distinguish among various resource allocation requests. The following requests are supported: M-Type = 0x01: add request: this context is used when the PEP generates a new request to the PDP; M-Type = 0x02: release request: this context is used when the PEP wants to delete resources allocated by a previous request; M-Type = 0x03: modify request: this context is used when the PEP wants to change the parameters passed in the previous request; 2.3 X-COPS Protocol Objects All the objects described in this section have to be intended as objects/attributes encapsulated within other "higher level" COPS objects. In particular, they are carried in the X-COPS Client Specific Information Object(section 3)for the PEP -> PDP communication, and in the Client Specific Decision Object (section 4) for the PDP -> PEP direction. These X-COPS objects have a TLV format (Type-Length-Value) where Type (16 bit) identifies univocally the object, Length (16 bit) indicates the length of the object in Bytes (including the header) and Value is the content of the object. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | | | Value | | | +---------------+---------------+---------------+---------------+ 2.4 Request ID Object (ReqID) Multiprotocol DiffServ interworking using COPS January 20022 This object is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP, or in the Client Specific Decision data sent from a PDP to a PEP. It allows to bind requests sent by the PEP and having the same COPS Handle Object with responses coming from the PDP (see [1]). This mechanism allows an X- COPS PEP to make more than one request for a specific state (identified by the Handle Object) before receiving a PDP response. The Request ID Object is chosen by the PEP and it is opaque to the PDP. For each request a different Request ID is chosen by the PEP. Request ID values can be reused if they are associated to different Handle Objects. Type = 1, Length = 8 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Request ID | +---------------+---------------+---------------+---------------+ 2.5 Source Host IPv4 address Object (SrcIP) This object specifies the IPv4 address of the host originating the flow for which a PDP decision is requested. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The host IP address could be useful to the Bandwidth Broker in order to perform Authorization operations. Type = 2, Length = 8 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Source IPv4 Address | +---------------+---------------+---------------+---------------+ 2.6 Destination IPv4 address Object (DstIP) This object specifies the IPv4 address of the host which is the destination of the flow that requires a PDP decision. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The destination address is needed each time the BR is not aware of the egress router for the traffic flow for which is performing the request. Type = 3, Length = 8 0 1 2 3 Multiprotocol DiffServ interworking using COPS January 20022 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Destination IPv4 Address | +---------------+---------------+---------------+---------------+ 2.7 Source Host IPv6 address Object (SrcIPv6) This object specifies the IPv6 address of the host originating the flow for which a PDP decision is requested. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. Type = 4, Length = 20 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | | + + | | + + | Source Host IPv6 Address | + + | | +---------------+---------------+---------------+---------------+ 2.8 Destination IPv6 address Object (DstIPv6) This object specifies the IPv6 address of the host, which is the destination of the flow that requires a PDP decision. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The destination address is needed each time the BR is not aware of the egress router for the traffic flow for which is performing the request. Type = 5, Length = 20 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | | + + | | + + | Destination Ipv6 Address | + + Multiprotocol DiffServ interworking using COPS January 20022 | | +---------------+---------------+---------------+---------------+ 2.9 Ingress Border Router Interface Object/TrunkID (IPv4BRIf) This object specifies the IPv4 address of the ingress border router output interface for the traffic flow which requires resource allocation. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. Besides this object specifies the label (either with a DiffServ semantics, i.e. DSCP, or with another semantics, e.g MPLS) requested for the traffic flow. The couple IP address/label specifies univocally the trunk where the traffic flow has to be aggregated. Type = 6, Length = 16 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Ingress BR Output Interface | +---------------+---------------+---------------+---------------+ | Label Type | +---------------+---------------+---------------+---------------+ | Label | +---------------+---------------+---------------+---------------+ The Label Type field is used to specify the semantics of the label: Label Type = 0x00000001: DiffServ; Label Type = 0x00000002: MPLS; Label Type = 0x00000003: ATM; Label Type = ...; 2.10 Ingress Border Router Interface Object/TrunkID (IPv6BRIf) This object specifies the IPv6 address of the ingress border router output interface for the traffic flow which requires resource allocation. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. Besides this object specifies the label (either with a DiffServ semantics, i.e. DSCP, or with another semantics, e.g. MPLS) requested for the traffic flow. The couple IP address/label specifies univocally, for the BR, the trunk where the traffic flow has to be aggregated. Type = 7, Length = 28 Multiprotocol DiffServ interworking using COPS January 20022 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | | + + | | + Ingress BR Output Interface Ipv6 Address + | | + + | | +---------------+---------------+---------------+---------------+ | Label Type | +---------------+---------------+---------------+---------------+ | Label | +---------------+---------------+---------------+---------------+ The Label Type field is used to specify the semantics of the label: Label Type = 0x00000001: DiffServ; Label Type = 0x00000002: MPLS; Label Type = 0x00000003: ATM; Label Type = ...; 2.11 Egress Border Router Interface Object (IPv4ER) This object specifies the IPv4 Egress Border Router interface address for the traffic flow for which the resource allocation request is performed. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. Type = 8, Length = 8 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Egress BR Input Interface IPv4 Address | +---------------+---------------+---------------+---------------+ 2.12 IPv6 Egress Border Router Interface Object (IPv6ER) This object specifies the IPv6 Egress Border Router interface address for the traffic flow for which the resource allocation request is performed. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. Multiprotocol DiffServ interworking using COPS January 20022 Type = 9, Length = 20 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | | + + | | + Egress BR Input Interface Ipv6 Address + | | + + | | +---------------+---------------+---------------+---------------+ 2.13 Traffic Type Object (Ttype) Type = 10, Length = 16 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Traffic Type ID | +---------------+---------------+---------------+---------------+ Traffic Type IDs are maintained in the form of a list where each Traffic Type ID value corresponds to a predefined (either standardized or client defined) characterization: Traffic Type ID = value -> characterization Traffic Type ID = ... Traffic Type ID = ... Traffic Type Object and Traffic Characterization Object, described in the next paragraph, can be used together or separately, allowing to specify traffic parameters at different levels. 2.14 Traffic Characterization Object (Tchar) The traffic characterization object describes the traffic characterization parameters for the traffic flow. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The Characterization Type value specifies the type of characterization attached to the object. Type = 11, Length = variable 0 1 2 3 Multiprotocol DiffServ interworking using COPS January 20022 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Characterization Type | +---------------+---------------+---------------+---------------+ | Characterization | + + | ... | + + | ... | +---------------+---------------+---------------+---------------+ The following characterization type are supported: Characterization Type = 1 (0x00000001): Average Rate & Peak(r, p, m, M); Characterization Type = 2 (0x00000002): LBAP point (r, b, p, m, M, avgr); Characterization Type = 3 (0x00000003): 3D LBAP point (l, r, b, p, M, avgr); Characterization Type = 4 (0x00000004): LBAP (p, m, M, avgr,(r, b) plot); Characterization Type = 5 (0x00000005): 3D-LBAP (p, m, M, avgr, (l, (r,b) plot,...,l, (r,b) plot)); where r indicates the rate (bytes/s), b the bucket size (bytes), p the peak rate (bytes/s), m the minimum policed unit (bytes), M the connection MTU (bytes), avgr the average rate (bytes/sec) and l the loss probability. 2.14.1 Characterization Type 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Peak Rate | +---------------+---------------+---------------+---------------+ | Minimum policed unit | +---------------+---------------+---------------+---------------+ | Connection MTU | +---------------+---------------+---------------+---------------+ 2.14.2 Characterization Type 2 0 1 2 3 +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ Multiprotocol DiffServ interworking using COPS January 20022 | Bucket Size | +---------------+---------------+---------------+---------------+ | Peak Rate | +---------------+---------------+---------------+---------------+ | Minimum policed unit | +---------------+---------------+---------------+---------------+ | Connection MTU | +---------------+---------------+---------------+---------------+ | Average Rate | +---------------+---------------+---------------+---------------+ 2.14.3 Characterization Type 3 0 1 2 3 +---------------+---------------+---------------+---------------+ | Loss Probability | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ | Peak Rate | +---------------+---------------+---------------+---------------+ | Minimum policed unit | +---------------+---------------+---------------+---------------+ | Connection MTU | +---------------+---------------+---------------+---------------+ | Average Rate | +---------------+---------------+---------------+---------------+ 2.14.4 Characterization Type 4 0 1 2 3 +---------------+---------------+---------------+---------------+ | Peak Rate | +---------------+---------------+---------------+---------------+ | Minimum policed unit | +---------------+---------------+---------------+---------------+ | Connection MTU | +---------------+---------------+---------------+---------------+ | Average Rate | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ Multiprotocol DiffServ interworking using COPS January 20022 2.14.5 Characterization Type 5 0 1 2 3 +---------------+---------------+---------------+---------------+ | Peak Rate | +---------------+---------------+---------------+---------------+ | Minimum policed unit | +---------------+---------------+---------------+---------------+ | Connection MTU | +---------------+---------------+---------------+---------------+ | Average Rate | +---------------+---------------+---------------+---------------+ | Loss Probability | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ | ... | | ... | +---------------+---------------+---------------+---------------+ | Loss Probability | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ | Rate | +---------------+---------------+---------------+---------------+ | Bucket Size | +---------------+---------------+---------------+---------------+ 2.15 QoS Class Description Object (QoSDesc) This object specifies the QoS class to which the traffic flow belongs to. Four different QoS classes are defined: Class Type = 0x00000001: bounded losses; Class Type = 0x00000002: guaranteed bandwidth; Class Type = 0x00000003: guaranteed bandwidth + bounded delay; Multiprotocol DiffServ interworking using COPS January 20022 Class Type = 0x00000004: guaranteed bandwidth + bounded delay + bounded jitter. Each one of this classes has more stringent QoS guarantees than the previous class. Type = 12, Length = variable 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Class Type | +---------------+---------------+---------------+---------------+ 2.16 QoS Parameters Description Object (QoSPrms) This object defines the QoS parameters requested. Four different parameters are defined: bandwidth; delay; jitter; loss probability; For each of the previous parameters a slack term could be indicated: while the bandwidth slack term must be subtracted to the bandwidth paramter in order to find the minimum allowed bandwidth, the jitter and delay slack terms must be added to the respective parameters in order to find the maximum allowed delay and jitter. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Bandwidth (bytes/sec) | +---------------+---------------+---------------+---------------+ | Bandwidth Slack Term | +---------------+---------------+---------------+---------------+ | Jitter (msec) | +---------------+---------------+---------------+---------------+ | Jitter Slack Term | +---------------+---------------+---------------+---------------+ | Delay (msec) | +---------------+---------------+---------------+---------------+ | Delay Slack Term | +---------------+---------------+---------------+---------------+ 2.17 X-COPS Decision Object (X-COPSDec) Multiprotocol DiffServ interworking using COPS January 20022 This object is used by the PDP to inform the PEP how to aggregate the flow. It is carried in the Client Specific Decision Data Object of a Decision Message sent from a PDP to a PEP. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Label Type | +---------------+---------------+---------------+---------------+ | Label | +---------------+---------------+---------------+---------------+ Label Type: Label Type = 0x00000001: DiffServ; Label Type = 0x00000002: MPLS; Label Type = 0x00000003: ATM; Label Type = ...; The Label value is set according to the specified Label Type. 2.18 Temporal information object (TempInfo) The temporal information object is used to specify the time interval inside which the request is valid. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP.By means of this object one or more time intervals and/or periodically repeated time intervals could be defined. An ASCIIZ string is used to describe the temporal information. If the string length is not multiple of 32 bits appropriate zero padding bytes are used. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | ASCII string | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ The ASCII string is in the form: {[ ] [ ]... ... ...[ ]} where: start date and end date are in the format: "ddmmyyyy"; start day of the week and end day of the week are expressed by one of the following character: A-B-C-D-E-F-G. The letters are the coding for: sun _ mon _ tue _ wen _ thu _ fri _ sat respectively; start hour and end hour are in the format: "hhmm". Blanks, present in the string above, are used for increase the readability, and are suppressed in the TempInfo object value. The ASCII string starts with "{" and ends with "}". Each time interval is specified internally to the characters "[" and "]". This time interval is the intersection of the time intervals (separated by the character "-") specified internally to the characters "<" and ">". Otherwise the global time interval is the union of all the time intervals specified internally to the characters "[" and "]". The character ("*") is used as wildcard. As an example, the ASCII string {[<15092001-15122001><1600- 1800>] [<01042002-30062002><*><1700-1900>]} means: every Monday, Wednesday and Friday between September the 15th and December the 15th 2001, from 16:00 to 18:00 and everyday between April the 1st and June the 30th 2002, from 17:00 to 19:00. This string could be, e.g , used to perform a resource allocation request for a tele_teaching scenario. 2.19 Reject Reason Object (RejRea) This object specifies the reason of a negative answer coming from the PDP. It is carried in the Client Specific Decision Data Object of a Decision Message sent from a PDP to a PEP. Reason Code: Reason Code = 0x00000001: Resource unavailable; Reason Code = 0x00000002: Unsupported Traffic Type; Reason Code = 0x00000003: Unacceptable Src Address; Reason Code = 0x00000004: Unacceptable Dst Address; Reason Code = ...; 3. X-COPS Client Specific Information Object (X-COPS ClientSI) Multiprotocol DiffServ interworking using COPS January 20022 3.1 X-COPS Client Specific RAR data The X-COPS Client Specific Resource Allocation Request data (RAR) is carried in the REQ messages for the X-COPS client and contains the description of the resources and has a different format depending on whether the type of request is Add/Release or Modify. For Add and Release messages the X-COPS ClientSI RAR is: ::= [] [] [] [] [] [] [] [] [] [] [] [] [] with: X(s) ::= | whether for the Modify messages is: ::= [] (new) [] (old) [](new) [] (old) [](new) [](old) Multiprotocol DiffServ interworking using COPS January 20022 [](new) [](old) [](new) [](old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) 3.2 X-COPS Client Specific Decision data The X-COPS ClientSI Decision data is carried in the COPS decision message and contains the PDP decision for a certain Request ID. ::= < X-CopsDec> | < RejRea> [] [] [] [] [] [] [] Multiprotocol DiffServ interworking using COPS January 20022 [] [] [] [] 4. Message content 4.1 Request Message (REQ) PEP -> PDP ::= [] [] [] [] 4.2 Decision Message (REQ) PDP -> PEP ::= | [] ::= 4.3 Report State Message (RPT) PEP -> PDP The RPT Message is sent by the PEP to PDP in case of problems with a received Decision Message. RPT Message has the following format: ::= Multiprotocol DiffServ interworking using COPS January 20022 [] ::= 5. Security consideration See [1]. Multiprotocol DiffServ interworking using COPS January 20022 References [1] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, January 2000 [2] S. Herzdog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry "COPS Usage for RSVP", IETF RFC 2749, January 2000 Author's Addresses Giacomo Sergio META CPR 116, Corso Italia, Phone: +39-050-915825 56125 Pisa, Italy Email: g.sergio@cpr.it Nicola Ciulli META CPR 116, Corso Italia, Phone: +39-050-915825 56125 Pisa, Italy Email: n.ciulli@cpr.it Valentina Chionsini University of Pisa, Department of Information Engineer 2, Via Diotisalvi, Phone: +39-050-568661 56125 Pisa, Italy Email: v.chionsini@iet.unipi.it